> Why do you describe these as two separate regions? Actually they always
> follow one
> another, and CONTROL area has peripherial IDs at the end, so we can perfectly
> merge
them.
And one more note. Could you omit ITS region reservations from the next
version at all? I
think ITS implementati
Hi everybody!
I started to play with ITS implementation and got another question.
> +[VIRT_ITS_CONTROL] = { 0x0802, 0x0001 },
> +[VIRT_ITS_TRANSLATION] = { 0x0803, 0x0001 },
Why do you describe these as two separate regions? Actually they always follow
one
another
Hello!
> I accept that virtv2 is not needed and I'm currently using Pavel's patch
> https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg02930.html with small
> modifications.
> However If there is a consensus I'll move to Ashok's virt instead of Pavel's
> one.
>
> I'm looking forward for a
> -Original Message-
> From: Eric Auger [mailto:eric.au...@linaro.org]
> Sent: Tuesday, 19 May, 2015 5:39 PM
> To: shlomopongr...@gmail.com; qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; Shlomo Pongratz
> Subject: Re: [Qemu-devel] [PATCH RFC V2 4/4] Add virtv2
Hi Shlomo,
On 05/06/2015 04:04 PM, shlomopongr...@gmail.com wrote:
> From: Shlomo Pongratz
>
> There is a need to support flexible clusters size. The GIC-500 can support
> up to 128 cores, up to 32 clusters and up to 8 cores is a cluster.
> So for example, if one wishes to have 16 cores, the opti
On Thursday, May 7, 2015, Pavel Fedin wrote:
> Hello!
>
> > The issue is similar to what you have noticed.
>
> In this case it's probably not your fault.
>
> > The larger the number of smp cores it is more likely that the boot will
> get stuck.
> > I've commuted this patch series as an RFC becau
Hello!
> My current guest kernel is v3.19.5. I will test on 4.1rc2 soon.
Retested with 4.1.0rc2 (linux-stable.git master). Works perfectly fine with up
to 8 CPUs. Here is boot log from 16 CPUs, listing potential problems:
--- cut ---
Initializing cgroup subsys memory
Initializing cgroup subsy
Hello!
> The issue is similar to what you have noticed.
In this case it's probably not your fault.
> The larger the number of smp cores it is more likely that the boot will get
> stuck.
> I've commuted this patch series as an RFC because of this issue.
I have tried to give more testing to it
On Thursday, May 7, 2015, Pavel Fedin wrote:
> Hello!
>
> ➢ Thank you for your comment, I might do it after solving the stability
> issues.
>
> What kind of stability issues do you have ?
> You know, i was testing 64-bit qemu in TCG mode, and i have also seen
> weird behavior. The kernel just
Hello!
➢ Thank you for your comment, I might do it after solving the stability issues.
What kind of stability issues do you have ?
You know, i was testing 64-bit qemu in TCG mode, and i have also seen weird
behavior. The kernel just stops and waits until you hit any key on the console,
then
On Thursday, May 7, 2015, Pavel Fedin wrote:
> Hello!
>
> Why do we need 'virt2' ? I am currently working on testing your
> implementation, and i try to use different approach. I see this as
> '-machine
> virt,gicv=N' option, where N is 2 or 3. Isn't it better than duplicating
> the
> whole vir
Hello!
Why do we need 'virt2' ? I am currently working on testing your
implementation, and i try to use different approach. I see this as '-machine
virt,gicv=N' option, where N is 2 or 3. Isn't it better than duplicating the
whole virt.c code just for single different function ?
Kind regards,
P
From: Shlomo Pongratz
There is a need to support flexible clusters size. The GIC-500 can support
up to 128 cores, up to 32 clusters and up to 8 cores is a cluster.
So for example, if one wishes to have 16 cores, the options are:
2 clusters of 8 cores each, 4 clusters with 4 cores each
Currently o
13 matches
Mail list logo
