qemu-devel
[Top][All Lists]
Advanced

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

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [RFC] [PATCH 0/3] qemu: arm: Migration between machines with different MIDR values
Date: Fri, 5 Oct 2018 09:48:35 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

* Peter Maydell (address@hidden) wrote:
> On 4 October 2018 at 16:05, Andrew Jones <address@hidden> wrote:
> > On Tue, Oct 02, 2018 at 02:07:38PM +0100, Peter Maydell wrote:
> >> 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.
> 
> I can see the logic of that approach. But right now QEMU
> userspace knows basically nothing about the system registers
> when we're using KVM: all that knowledge is in the kernel.
> So we don't have a place really to put policy info (and
> not really anywhere to put policy info that depends on the
> host CPU type when mostly we let the kernel care about that).

It would seem wrong to put this logic in the kernel because the
priviliged code should be as small as possible.

Dave

> >> 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.
> 
> Patching QEMU to ignore all attempts to write wrong values
> to read-only registers would be easy. It just wouldn't
> be very helpful to the user...
> 
> thanks
> -- PMM
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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