I didn't say that calling this function here will lead to a bug. I am saying that+static void vmx_set_apic_access_page_addr(struct kvm *kvm, hpa_t hpa)This shouldn't even been called if apic access page is not supported. Nor
+{
+ if (vm_need_virtualize_apic_accesses(kvm))
mmu_notifier path neither tdp_page_fault path should ever see 0xfee00000
address. BUG() is more appropriate here.
I don't quite understand. Why calling this function here will leed to bug ?
(Sorry, I'm not quite understand the internal of KVM. Please help.)
if vm_need_virtualize_apic_accesses() is false this function should not be called
at all, so this check is redundant.
Right, kvm->arch.apic_access_page is just a shadow value for whatever is written+ if (kvm->arch.apic_access_page_migrated) {All vcpus will access apic_access_page without locking here. May be
+ if (kvm->arch.apic_access_page)
+ kvm->arch.apic_access_page = pfn_to_page(0);
set kvm->arch.apic_access_page to zero in mmu_notifier and here call
kvm_x86_ops->set_apic_access_page_addr(kvm, kvm->arch.apic_access_page);
I'm a little confused. apic access page's phys_addr is stored in vmcs, and
I think it will be used by vcpu directly to access the physical page.
Setting kvm->arch.apic_access_page to zero will not stop it, right ?
in vmcs. After setting it all vcpus need to update their vmcs values.
I'm wondering what happens when apic page is migrated, but the vmcs is stillapic page should not be migrated untill all vpus are forced out of a guest mode and
holding its old phys_addr before the vcpu request is handled.
instructed to reload new value on a next guest entry. That's what we are trying to
achieve here.