Re: Heads up: More user-unaccessible x86 states?

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]