On 11 August 2015 at 11:39, Pavel Fedin wrote:
> By the way, how to migrate such a thing? Is migration of
> variable-length state structures supported?
Yes; this is what the _VARRAY_ vmstate macros are for.
-- PMM
Hello!
> In any case, if you want
> to impose a compile-time limit in the QEMU code then you need
> to point out the part of the GIC spec that imposes that limit.
Ok, i agreed and gave up. Will do in v9. :)
By the way, how to migrate such a thing? Is migration of variable-length state
structu
On 11 August 2015 at 10:35, Pavel Fedin wrote:
> Hello!
>
>> No it won't, because "don't impose an arbitrary 64 bit limit"
>> was one of my review comments on the emulation code; that
>> will need to be fixed before the emulation code can be accepted.
>
> Sorry for may be being ignorant, i reall
Hello!
> No it won't, because "don't impose an arbitrary 64 bit limit"
> was one of my review comments on the emulation code; that
> will need to be fixed before the emulation code can be accepted.
Sorry for may be being ignorant, i really had no time to read GICv3 arch
manual from beginning t
On 11 August 2015 at 08:53, Pavel Fedin wrote:
>> > +#define GICV3_NCPU 64
>>
>> What is imposing this NCPU limit?
>
> Currently qemu does not support Aff2 field. Can we have more
> than 64 CPUs only with Aff0 and Aff1?
The GIC code itself doesn't care, so it shouldn't be imposing
its own limit,
> > +#define GICV3_NCPU 64
>
> What is imposing this NCPU limit?
Currently qemu does not support Aff2 field. Can we have more than 64 CPUs only
with Aff0 and Aff1?
Well, if you really-really insist, i can just raise it to 128 and stop it
finally. It's actually Shlomo's heritage, and i believe
On 10 August 2015 at 13:06, Pavel Fedin wrote:
> From: Shlomo Pongratz
>
> This class is to be used by both software and KVM implementations of GICv3
>
> Currently it is mostly a placeholder, but in future it is supposed to hold
> qemu's representation of GICv3 state, which is necessary for migra
From: Shlomo Pongratz
This class is to be used by both software and KVM implementations of GICv3
Currently it is mostly a placeholder, but in future it is supposed to hold
qemu's representation of GICv3 state, which is necessary for migration.
Signed-off-by: Shlomo Pongratz
Signed-off-by: Pave
