On Thu, Jan 29, 2015 at 10:54 AM, Zhang, Yang Z <yang.z.zhang@xxxxxxxxx> wrote:
>> -8646,7 +8750,8 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu,
>> struct vmcs12 *vmcs12)
>> else
>> vmcs_write64(APIC_ACCESS_ADDR,
>>
>> page_to_phys(vmx->nested.apic_access_page));
>> - } else if
>> (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm)) {
>> + } else if (!(nested_cpu_has_virt_x2apic_mode(vmcs12)) &&
>> +
>> + (vm_need_virtualize_apic_accesses(vmx->vcpu.kvm))) {
>> exec_control |=
>
> You don't load L2's apic_page in your patch correctly when x2apic mode is used. Here is the right change for prepare_vmcs02()(maybe other place also need change too):
>
> @@ -8585,7 +8585,8 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12)
> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS))
> exec_control |= vmcs12->secondary_vm_exec_control;
>
> - if (exec_control & SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES) {
> + if (exec_control & (SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
> + SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE)) {
> /*
> * If translation failed, no matter: This feature asks
> * to exit when accessing the given address, and if it
> @@ -8594,7 +8595,8 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12)
> */
> if (!vmx->nested.apic_access_page)
> exec_control &=
> - ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
> + ~ (SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
> + SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE);
> else
> vmcs_write64(APIC_ACCESS_ADDR,
> page_to_phys(vmx->nested.apic_access_page));
>
I think we don't need to do this, if L1 enables x2apic mode, we have
already checked that the
vmcs12->SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES is 0. "exec_control |=
vmcs12->secondary_vm_exec_control;" merged L1's settings, including
x2apic mode. the special case is vm_need_virtualize_apic_accesses, if
vm_need_virtualize_apic_accesses returns true, the
nested_cpu_has_virt_x2apic_mode will prevent us to set the apic access
bit.
Thanks,
Wincy
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
