[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 7/7] Nested VMX: Clear APIC-v control bit in vmcs02



Jan Beulich wrote on 2013-08-09:
>>>> On 09.08.13 at 10:49, Yang Zhang <yang.z.zhang@xxxxxxxxx> wrote:
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -617,6 +617,8 @@ void nvmx_update_secondary_exec_control(struct
> vcpu *v,
>>      shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx,
>>      SECONDARY_VM_EXEC_CONTROL); nvmx->ept.enabled = !!(shadow_cntrl &
>>      SECONDARY_EXEC_ENABLE_EPT); shadow_cntrl |= host_cntrl;
>> +    shadow_cntrl &= ~(SECONDARY_EXEC_APIC_REGISTER_VIRT |
>> +            SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY);
>>      __vmwrite(SECONDARY_VM_EXEC_CONTROL, shadow_cntrl);  }
>> @@ -627,6 +629,7 @@ static void nvmx_update_pin_control(struct vcpu
>> *v, unsigned long host_cntrl)
>> 
>>      shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx,
>>      PIN_BASED_VM_EXEC_CONTROL); shadow_cntrl |= host_cntrl; +   
>>      shadow_cntrl &= ~PIN_BASED_POSTED_INTERRUPT;
>>      __vmwrite(PIN_BASED_VM_EXEC_CONTROL, shadow_cntrl);  }
> 
> I can see why you want to mask the bit off of host_cntrl, but is it
> really correct to also mask it when set in the vVMCS? Shouldn't that
> rather result in a fault raised to it? (If that's already the case
> - I just don't know the nested code well enough yet - then this would
> still call for being adjusted logically: Mask the bit when or-ing in
> host_cntrl, and assert that the bit is clear in what you read from
> vVMCS. This would make much more obvious what the intentions here are.
Sure, it sounds much reasonable.

> 
> Jan


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.