On 4 October 2018 at 16:05, Andrew Jones <drjo...@redhat.com> 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). >> 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
