Avi Kivity wrote: > On 10/04/2009 09:07 PM, Jan Kiszka wrote: >>> btw, instead of adding a new ioctl, perhaps it makes sense to define a >>> new KVM_VCPU_STATE structure that holds all current and future state >>> (with generous reserved space), instead of separating state over a dozen >>> ioctls. >>> >>> >> OK, makes sense. With our without lapic state? > > I'm in two minds. I'm leaning towards including lapic but would welcome > arguments either way. The lapic is optional and, thus, typically handled in different code modules by user space. QEMU even creates a separate device that holds the state. I'm not sure user space will benefit from a unified query/set interface with regard to this. > > Note we have to be careful with timers such as the tsc and lapic timer. > Maybe have a bitmask at the front specifying which elements are active. ...and the lapic timers are another argument. Regarding TSC, which means MSRs: I tend to include only states into the this meta state which have fixed sizes. Otherwise things will get very hairy. And the GET/SET_MSRS interface is already fairly flexible, the question would be again: What can we gain by unifying? > >> How much "future space"? >> > > avx will change the sse registers from 16x16 to 16x32, with a hint of > more to come. Nested vmx needs the vmptr and some more bits. MSRs are > potentially endless. Lots of space. > Hmm, a some kB then (even without MSRs)... Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
