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().
--
Gleb.
--
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
