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

[Peter Maydell <peter.maydell@linaro.org>]

On 5 October 2018 at 09:48, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> On 4 October 2018 at 16:05, Andrew Jones <drjones@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