Re: [PATCH 3/24] Implement VMXON and VMXOFF

[Avi Kivity <avi@redhat.com>]

On 06/16/2010 02:14 PM, Nadav Har'El wrote:
> Hi,
>
> On Mon, Jun 14, 2010, Avi Kivity wrote about "Re: [PATCH 3/24] Implement VMXON and VMXOFF":
>    
>> On 06/13/2010 03:24 PM, Nadav Har'El wrote:
>>      
>>> This patch allows a guest to use the VMXON and VMXOFF instructions, and
>>> emulates them accordingly. Basically this amounts to checking some
>>> prerequisites, and then remembering whether the guest has enabled or
>>> disabled
>>> VMX operation.
>>>        
>> Should probably reorder with next patch.
>>      
> I can't do this if I want the code to compile after each patch, because the
> next patch (controlling when setting cr4.VMXE can be set) needs to check
> whether VMXON was done.
>    

You can have this patch add the vmxon check.  But it doesn't matter too 
much, you can keep the current order.

>> Need to block INIT signals in the local apic as well (fine for a
>> separate patch).
>>      
> I've been looking into how I might best go about achieving this.
>
> The APIC_DM_INIT handler is in lapic.c, which is not aware of VMX or
> (obviously) nested VMX. So I need to add some sort of generic "block INIT"
> flag which that code will check. Is this the sort of fix you had in mind?
>    

It's not enough to block INIT, there is also exit reason 3, INIT 
signal.  So you need to call x86.c code from the lapic, which needs to 
call a kvm_x86_op hook which lets vmx.c decide whether the INIT needs to 
be intercepted or not, and what to do with it (ignore in root mode, exit 
in non-root mode)

Note the check needs to be done in vcpu context, not during delivery as 
it is done now.  So we probably need a KVM_REQ_INIT bit in 
vcpu->requests, which we can check during guest entry where we know if 
we're in root or non-root mode.

Pretty complicated and esoteric.  We can defer this now while we work 
out more immediate issues, but it needs to be addressed.

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