Re: [Qemu-devel] [RFC] [PATCH 0/3] qemu: arm: Migration between machines with different MIDR values

[Andrew Jones]

On Tue, Oct 02, 2018 at 02:07:38PM +0100, Peter Maydell wrote:
> On 27 September 2018 at 02:13,  <address@hidden> wrote:
> > From: Manish Jaggi <address@hidden>
> >
> > QEMU on arm systems use -machine virt -cpu host option for a VM.
> > Migration thus is limited between machines with same cpu.
> >
> > This is a limitation if migration is desired between cpus which are of same
> > family and have only few diferences like bug fixes which have no effect on
> > VM operation. They just differ in say MIDR values.
> >
> > This patchset introduces a command line option -skipinvariant. Invariant
> > registers will be skipped from being restored from guests context on 
> > migrated
> > host.
> >
> > Mailing list discussion on this topic:
> > https://www.mail-archive.com/address@hidden/msg560043.html
> 
> Hi; thanks for this patch. The issue I see with this patch
> is that the KVM/ARM QEMU approach to system registers so far
> has been "the kernel knows about these and it is in control".
> So we ask the kernel for the list of registers, and just save
> and restore those. That would suggest that if there are sysregs
> where it's OK in fact to ignore a difference between two constant
> register values, it should be the kernel doing the "actually, this
> mismatch is OK" behaviour...

I don't think the kernel should have to maintain all that logic. If a user
wants to load guest registers, then the kernel should do it, as long as
it's safe from the host's integrity/security PoV, and the hardware would
actually support it. Anything that can only break the guest, but not the
host, should be allowed. The KVM userspace can certainly ask the kernel
what it recommends first (i.e. read the invariant registers first, before
deciding what to write), but the decision of what to write should be left
up to the user.

> 
> For instance, it's probably OK to ignore a MIDR_EL1 difference
> that just indicates a minor revision bump; but not to ignore
> one that indicates you just tried to migrate a Cortex-A53
> over to a Cavium CPU.

If the user does that, then the guest will break - oh well. That's not the
host kernel's problem.

Thanks,
drew