On 10/05/2009 09:43 AM, Jan Kiszka wrote:
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.
avx registers, nested vmx are optional as well.
I'm not sure user space will benefit from a unified query/set
interface with regard to this.
The main benefit is to avoid creating an ioctl each time we find a
missing bit.
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?
For MSRs, not much.
Note we can make it work, by storing an offset/length at a fixed
location and letting userspace point it into the reserved area.
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)...
Yup, it's amazing how much state modern processors hold.
--
error compiling committee.c: too many arguments to function
--
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
