Wincy Van wrote on 2015-01-29: > On Thu, Jan 29, 2015 at 10:54 AM, Zhang, Yang Z > 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. I just realized that we are talking different thing. I am thinking about VIRTUAL_APIC_PAGE_ADDR(my mistake :)). And it has been handled correctly already. For APIC_ACCESS_ADDR, you are right. The current implementation can handle it well. > > > Thanks, > Wincy Best regards, Yang {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I