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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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