Hi Gleb,
On 09/03/2014 11:04 PM, Gleb Natapov wrote:
On Wed, Sep 03, 2014 at 09:42:30AM +0800, tangchen wrote:
Hi Gleb,
On 09/03/2014 12:00 AM, Gleb Natapov wrote:
......
+static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
+{
+ /*
+ * apic access page could be migrated. When the page is being migrated,
+ * GUP will wait till the migrate entry is replaced with the new pte
+ * entry pointing to the new page.
+ */
+ vcpu->kvm->arch.apic_access_page = gfn_to_page(vcpu->kvm,
+ APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
+ kvm_x86_ops->set_apic_access_page_addr(vcpu->kvm,
+ page_to_phys(vcpu->kvm->arch.apic_access_page));
I am a little bit worried that here all vcpus write to
vcpu->kvm->arch.apic_access_page
without any locking. It is probably benign since pointer write is atomic on
x86. Paolo?
Do we even need apic_access_page? Why not call
gfn_to_page(APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT)
put_page()
on rare occasions we need to know its address?
Isn't it a necessary item defined in hardware spec ?
vcpu->kvm->arch.apic_access_page? No. This is internal kvm data structure.
I didn't read intel spec deeply, but according to the code, the page's
address is
written into vmcs. And it made me think that we cannnot remove it.
We cannot remove writing of apic page address into vmcs, but this is not done by
assigning to vcpu->kvm->arch.apic_access_page, but by vmwrite in
set_apic_access_page_addr().
OK, I'll try to remove kvm->arch.apic_access_page and send a patch for
it soon.
BTW, if you don't have objection to the first two patches, would you
please help to
commit them first ?
Thanks.
--
Gleb.
.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
