Messages in this thread | | | Date | Tue, 9 Sep 2014 15:13:07 +0800 | From | tangchen <> | Subject | Re: [PATCH v4 4/6] kvm, mem-hotplug: Reload L1' apic access page on migration in vcpu_enter_guest(). |
| |
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. > . >
| |