On 5 October 2018 at 09:48, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * Peter Maydell (peter.mayd...@linaro.org) wrote: >> 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). > > It would seem wrong to put this logic in the kernel because the > priviliged code should be as small as possible.
Agreed. But if we want to move to "QEMU knows about all the possible host CPUs" that's a fair-sized design change and needs more than the minimalist approach this patch has. thanks -- PMM
