[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christoffer Dall
Subject: Re: [Qemu-devel] [PATCH 0/7] target-arm: cpregs list for migration, kvm reset
Date: Thu, 30 May 2013 17:11:41 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]