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

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

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

Avi Kivity wrote:
> On 10/04/2009 12:50 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>   
>>> On 10/04/2009 10:59 AM, Jan Kiszka wrote:
>>>     
>>>> Hi,
>>>>
>>>> while preparing new IOCTLs to let user space query&   set the yet
>>>> unaccessible NMI states (pending and masked) I also came across the
>>>> interrupt shadow masks. Unless I missed something I would say that
>>>> we so
>>>> far break them in the rare case that a migration happens right while
>>>> any
>>>> of them is asserted. So I guess I should extend my interface and stuff
>>>> them in as well.
>>>>
>>>> Do we have more of such unaccessible states on x86 that could be
>>>> included, too? Would be a good chance...
>>>>
>>>>        
>>> There's some hidden state in the cpuid mechanism.  I think we expose it
>>> though (just don't use it in qemu).
>>>      
>> Do you have more details on this?
>>    
> 
> Some cpuid leaves return different information based on an internal
> counter.  This is indicated by KVM_CPUID_FLAG_STATEFUL_FUNC.
> 
>> The PDPTRs are hidden state that we should save/restore, though no sane
>> guest relies on them.
>>    A quick glance at SVM makes me think that those registered are not
>> exposed there. So when keeping in mind that we may only help VMX guests,
>> I think i makes even less sense to "fix" this, does it?
>>    
> 
> Yes.  With npt the PDPTRs are essentially gone.
> 
>>> I think we can lose information if we migrate during a SIPI
>>> (sipi_vector), though that might be fixable without exposing it.
>>>      
>> Hmm, I see. But even it it's not fixable, such an extension would be an
>> in-kernel irqchip thing.
>>    
> 
> Yes.
> 
>>> We'll might also lost debug traps.
>>>
>>> We drop pending exceptions; normally that's fine since they'll reinject
>>> themselves, but MCE will not.
>>>      
>> So would it make sense and fix those two issues when we simply save and
>> restore the pending exception?
>>    
> 
> Yes.
> 
> 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? How much "future space"?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]