Re: [RFC 1/5] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code.

[Avi Kivity <avi@redhat.com>]

On 09/01/2012 03:18 AM, Peter Maydell wrote:
> On 1 September 2012 10:11, Avi Kivity <avi@redhat.com> wrote:
> > Other x86 state:
> >   Control registers: ok.  Should userspace be careful to set registers
> > in legal ways only? i.e. cannot set cr3[0:11] if cr4.pae=0, or vice
> > versa, so need three writes?
>
> The principle I'm hoping we can hold to for ARM is that the
> kernel only exposes state in such a way that it's always
> possible for userspace to migrate it with a simple "read
> everything, send to destination, write everything", ie
> without needing to know anything of the semantics of any
> of these registers.
>
> This means that registers which have access controls (eg
> "can't write this unless you wrote to that other one first")
> should not enforce those checks for userspace get/set.
> More significantly, it means that registers with odd
> behaviour, like "write 1 to clear" or "register A selects
> which of an array of underlying registers is exposed
> in register B" are not directly exposed at all. Instead
> the kernel provides some other (ersatz) register indexes
> which let userspace do plain get/set on the underlying
> state.

I came to the same conclusion.  It could be implemented via a
KVM_REQ_REEVALUATE, which causes all registers to be validated and
applied before guest entry.

> The idea is that then migration depends only on whether
> the destination kernel supports all the registers the
> source kernel does, and we avoid extra dependencies
> on the source and destination qemu. (Most of the state
> being transferred is of no interest to userspace at all.)
> [It also makes write-multiple easier to use.]

We also need to support migration to an earlier kernel.  That means new
state is not transferred (of course this state must not be exposed to
the guest).  There is also the hack with subsections: if we discover new
hidden state, then qemu can avoid transferring it to an older kernel,
provided the value matches the default (which should be often, otherwise
the bug would have been discovered much earlier).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.