[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 4/8] x86/mem-sharing: copy GADDR based shared guest areas
On 27.09.2023 16:05, Roger Pau Monné wrote: > On Wed, Sep 27, 2023 at 02:06:47PM +0200, Jan Beulich wrote: >> On 27.09.2023 13:08, Roger Pau Monné wrote: >>> On Wed, May 03, 2023 at 05:56:46PM +0200, Jan Beulich wrote: >>>> --- a/xen/arch/x86/mm/mem_sharing.c >>>> +++ b/xen/arch/x86/mm/mem_sharing.c >>>> @@ -1641,6 +1641,68 @@ static void copy_vcpu_nonreg_state(struc >>>> hvm_set_nonreg_state(cd_vcpu, &nrs); >>>> } >>>> >>>> +static int copy_guest_area(struct guest_area *cd_area, >>>> + const struct guest_area *d_area, >>>> + struct vcpu *cd_vcpu, >>>> + const struct domain *d) >>>> +{ >>>> + mfn_t d_mfn, cd_mfn; >>>> + >>>> + if ( !d_area->pg ) >>>> + return 0; >>>> + >>>> + d_mfn = page_to_mfn(d_area->pg); >>>> + >>>> + /* Allocate & map a page for the area if it hasn't been already. */ >>>> + if ( !cd_area->pg ) >>>> + { >>>> + gfn_t gfn = mfn_to_gfn(d, d_mfn); >>>> + struct p2m_domain *p2m = p2m_get_hostp2m(cd_vcpu->domain); >>>> + p2m_type_t p2mt; >>>> + p2m_access_t p2ma; >>>> + unsigned int offset; >>>> + int ret; >>>> + >>>> + cd_mfn = p2m->get_entry(p2m, gfn, &p2mt, &p2ma, 0, NULL, NULL); >>>> + if ( mfn_eq(cd_mfn, INVALID_MFN) ) >>>> + { >>>> + struct page_info *pg = alloc_domheap_page(cd_vcpu->domain, 0); >>>> + >>>> + if ( !pg ) >>>> + return -ENOMEM; >>>> + >>>> + cd_mfn = page_to_mfn(pg); >>>> + set_gpfn_from_mfn(mfn_x(cd_mfn), gfn_x(gfn)); >>>> + >>>> + ret = p2m->set_entry(p2m, gfn, cd_mfn, PAGE_ORDER_4K, >>>> p2m_ram_rw, >>>> + p2m->default_access, -1); >>>> + if ( ret ) >>>> + return ret; >>>> + } >>>> + else if ( p2mt != p2m_ram_rw ) >>>> + return -EBUSY; >>> >>> Shouldn't the populate of the underlying gfn in the fork case >>> be done by map_guest_area itself? >> >> I've used the existing logic for the info area to base my code on. As >> noted in the patch switching the info area logic to use the generalize >> infrastructure, I've taken the liberty to address an issue in the >> original logic. But it was never a goal to re-write things from scratch. >> If, as Tamas appears to agree, there a better way of layering things >> here, then please as a follow-on patch. > > Hm, I'm unsure the code that allocates the page and adds it to the p2m > for the vcpu_info area is required? map_vcpu_info() should already be > able to handle this case and fork the page from the previous VM. I don't think that's the case. It would be able to unshare, but the fork doesn't use shared pages aiui. I think it instead runs on an extremely sparse p2m, where pages from the parent are brought in only as they're touched. Tamas? Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |