Re: [PATCH 10/11] VMX: work around lacking VNMI support

[Jan Kiszka <jan.kiszka@siemens.com>]

Avi Kivity wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>> ..
>>  
>>> Index: b/arch/x86/kvm/vmx.c
>>> ===================================================================
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -90,6 +90,11 @@ struct vcpu_vmx {
>>>      } rmode;
>>>      int vpid;
>>>      bool emulation_required;
>>> +
>>> +    /* Support for vnmi-less CPUs */
>>> +    int soft_vnmi_blocked;
>>> +    ktime_t entry_time;
>>> +    s64 vnmi_blocked_time;
>>>     
>>
>> I meanwhile realized that these states (except entry_time) and probably
>> also arch.nmi_pending/injected are things that should be considered when
>> the vcpu state is saved and restored, right? What is the right interface
>> for this? An extension of kvm_sregs?
>>
>>   
> 
> kvm_sregs can't be extended because that would break the ABI, so we have
> to add a new ioctl.
> 
> I have some patches that allow ioctls to be extended, so if that's
> accepted, we can avoid the new ioctl.

OK.

> 
>> BTW, via which channel is GUEST_INTERRUPTIBILITY_INFO from the vmcs
>> saved/restored? I'm currently not seeing any related, CPU-specific code.
>>   
> 
> Looks like it's missing.

As a workaround (or safety bag), is it imaginable to delay or deny VCPU
snapshots at not yet fully restorable points (like
GUEST_INTERRUPTIBILITY_INFO != 0)? Or stick-your-head-into-the-sand for now?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux