[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |