On 09/01/2012 03:18 AM, Peter Maydell wrote: > On 1 September 2012 10:11, Avi Kivity <avi@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
