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

[Avi Kivity <avi@redhat.com>]

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