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

[Avi Kivity <avi@redhat.com>]

On 08/28/2012 04:45 PM, Rusty Russell wrote:
> Avi has indicated that this is the future.  For now, make it dependent on
> KVM_HAVE_ONE_REG (and define that for PPC and S/390).

I want GET_MULTI, really.  But maybe iterating over ONE_REG isn't so bad
since we do it so rarely.:

Would all register IDs fit in 64 bits?  cpuid (read only) is addressed
using eax (32-bits), ecx (for some values of eax), and yields 4 32-bit
values.  That's 66 bits of addressing, independent of some way to
discriminate between register sets.

I guess we could special case the cases where ecx is needed, or only
allow 8 bits for ecx (always okay so far).

Other x86 state:
  GPRs - ok
  MSRs - ok
  FPU - one register per xmm/st(x)? the entire xsave area?
  APIC  - one register per apic register? the entire 4k page?
  Various non-register state (pending exceptions, run state,
blocked-by-sti/ss) - ok
  SVM/VMX state - ok
  Segments: one register per segment? one per component?
  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?
  IOAPIC/PIC/PIT - not vcpu state
  Debug registers - ok
  xcr - ok
 
Yuch, we have a lot of state in that thing.


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