Re: [Qemu-devel] [PATCH 0/7] target-arm: cpregs list for migration, kvm reset

[Christoffer Dall <christoffer.dall@linaro.org>]

On Fri, May 17, 2013 at 02:23:50PM +0100, Peter Maydell wrote:
> This patch series overhauls how we handle ARM coprocessor registers,
> so that we use a consistent approach for migration, reset and
> QEMU<->KVM synchronisation, driven by the kernel's list of supported
> registers.
> 
> The basic principle here is that we trust the kernel's list of what
> registers it knows about, and that QEMU doesn't have to have specific
> knowledge of a coprocessor register to support running and migrating
> a KVM session on a kernel that does support that register.
> 
> We maintain a list of cp registers, which is initialized either from
> the current cpreg hashtable (for TCG), or by querying the kernel (for
> KVM).  For migration we simply send the lists of register indexes and
> values; migration fails if there's a register the destination kernel
> is unaware of, or if the value can't be set as required, but isn't
> gated on whether source or destination QEMU know about the register.
> 
> We also use the register list to properly reset the vcpu by simply
> feeding it back the initial set of register values; this fixes a bug
> where we weren't resetting everything we should have (though Linux
> guests don't care about most reset values).
> 
> Note that vm save/load with KVM requires that you run with -machine
> kernel_irqchip=off, because the kernel doesn't currently support
> save/load of either the VGIC or virtual timer state.  It may also be
> necessary to nobble the device tree blob to remove the "armv7-timer"
> node so the guest doesn't try to use the vtimers.  Migration between
> TCG and KVM is not supported at the moment (it would require us to
> add a lot of registers to TCG, which I may do at some point, but this
> is a bit of an obscure usecase IMHO).
> 

[...]

So there were some qemu magic in here that I didn't get into, so I
didn't do a full comprehensive review, but it looks pretty good overall,
and I couldn't spot any obvious bugs.

If we're ever going to benchmark live migration I have a feeling that
{GET/SET}_MULTIPLE_REGS interface that Alex once talked about may come
in handy, but until then I'm happy with exercising the kernel entry/exit
path a bit.

-Christoffer