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. -- 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
