[RFC PATCH 1/1] KVM: ARM: add vgic state save and restore support

[Peter Maydell]

On 4 December 2012 12:27, Dong Aisheng <b29396 at freescale.com> wrote:
> On Mon, Dec 03, 2012 at 01:22:07PM +0000, Peter Maydell wrote:
>> What we're really providing the guest here is a hardware-accelerated
>> software emulation of a no-virtualization GICv2. So it's better for
>> the state we expose to userspace to be the state of that emulated
>> hardware, and not to expose details of exactly what that hardware
>> acceleration is.
>
> It looks like a good idea.
> Then in which format? User space qemu and kernel space vgic are using
> different data format to describe gic state.
> We definitely need a standard one to use with good compatibility.
> One simple way may be just registers value of no-virtualization GICv2.

"Values of registers" and "state of a device" are not identical
(though the internal state is often made visible via registers).
We care about the latter, not the former.

> User space could convert the register value to whatever format it wants
> if needed. But that means we need to emulate gic cpu interface registers
> in kernel for user space to read which is also not so conveniently.

Yes, conversion code is tedious for somebody. My argument is that
the correct 'somebody' is the kernel.

>> The hw accel is a property of the host CPU,
>> not of the guest VM environment, so it could be different on
>> different kernels or host CPUs, which would make migration potentially
>> tedious. For instance, consider migration where the source machine
>> has a VGIC with more list registers than the destination machine.
>>
>
> Per my understanding,  qemu is a part of hypervisor, right?
> The it should be able to handle hw difference to support gic
> state saving running on different host.

No, it's userspace support code for the hypervisor. In particular,
it is the kernel that cares about the specific details of
exact host hardware we're running on. Userspace doesn't generally
see that level of detail.

> So i can not see big issue on exporting hw accel to qemu.

It could be done that way. I'm just arguing that the other
way is better: see my final paragraph quoted below.

>> Obviously you could convert between different representations
>> in a number of places (source kernel, source qemu, destination
>> qemu, destination kernel), but I think it makes sense for the
>> canonical representation to be the guest-visible representation
>> of the emulated hardware, rather than privileging any one
>> acceleration implementation above another.

PS: you don't need to quote my signature and the mailing list
footer in your reply emails...

-- PMM