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

[Avi Kivity <avi@redhat.com>]

On 10/05/2009 01:18 PM, Jan Kiszka wrote:
> Avi Kivity wrote:
>    
>> 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.
>>      
> Hmm, pointers... That makes me think of a meta IOCTL like this:
>
> struct kvm_vcpu_state {
> 	int substates;
> 	void __user *substate[0];
> };
>
>    

True pointers are no go since we have to deal with compat code (31/32 
bit userspace calling into a 64 bit kernel).  Offsets into the state 
structure are easier.

> #define KVM_VCPU_STATE_REGS  0 /* i.e. substate[0] points to kvm_regs */
> #define KVM_VCPU_STATE_SREGS 1
> #define KVM_VCPU_STATE_LAPIC 2
> ...
>
> We could easily extend the call with more substates just by defining new
> pointer slots. Moreover, user space could define which substates should
> be get/set by simply passing NULL or a valid pointer for substate[n] (or
> by limiting the substates field).
>
> The only ugliness I see is the missing type safety as we would have to
> deal with void pointers to the substate structures here.
>    

For fixed sized state a feature bitmap is sufficient I think.

-- 
error compiling committee.c: too many arguments to function