[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 5/9] x86/mem-sharing: copy GADDR based shared guest areas


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 28 Sep 2023 11:51:01 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WZ1uQIXpe/xn1a+D3xk0No54WWaT+xVrl3zYj54YSVk=; b=McY9bWTUx4NPJ54cvFED2NTdok4ml4+FATObFbpJ+IbMAeb35h5hcJvxUHC8ozJgDjxhrVV3agl++Q9YWM8aVG2pZx276dIOYLVZ3E+0EhkQAr7sNKZQMswww+xsIXEJoe3ZtyYKMvCC0oFn1DYKeFmH8Du2qwGqZs7604++GelqJVKV/c2yt948xlcQMhazXtHtSbdiavVd6z46LKouugRU81DNgjpv7XqhPbJubA7XDeug2Ang2E0wZ4hzTWweOElue/F5YfuSO5XTCXiui+cqzIl/EB5LTnJD06evJY5hIn+G4sT2Ip7bqKUWO9nRVg2EAZDJxrWqiQ5dBAebxA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gDcqFlAaDbGS/vaECUytldfg1mmBLDhfwYUUVifefHdVeziV/YHlWYLCaFGAfa4TSQL+loJQPiOXfWY5Yt1nYxCSlLIfujfjF+2CWebQNHfLRtJRFjJX5tZHUcbjhcIMpgUYj812I6V4nTlsuhSyIekr9aFWG9mkKT01srkCTb2nLKDjq6RiR0atxRz9phQTc0HbVdjzpdQD3LLT27+BuTbB9PtDK1si33MFP/VDb0/KRMg3UzH+KAX8jTb23nkQnL73WO/++Cke/xZrR6TxDDH6s3+DbFCvshfWJm3AOlHuc7IpNMO9CwEyPs3XQTa/+fSW2vDbiP2MiFkqCWA2wA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 28 Sep 2023 09:51:52 +0000
  • Ironport-data: A9a23:2vD5GKOh3J5u2RbvrR1UlsFynXyQoLVcMsEvi/4bfWQNrUoq02RTy WMXWmuPbvyJZjGjf98nYIW2pxtVsZLUxoM2Hgto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CQ6jefQAOOkVIYoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGjxSs/nrRC9H5qyo42tJ5AxmPJingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0rtRGUpSz /Y0EggQSC+vlvur5pSkYfY506zPLOGzVG8ekldJ6GiDSNwAEdXESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+PdxujaDpOBy+OGF3N79YNuFSN8Thk+Fj mnH4374ElcRM9n3JT+tqyjw2rGezHynMG4UPJG/radOqwah/HQWNB0oDkW9ndq7i0HrDrqzL GRRoELCt5Ma9kamU938VB2Qu2Ofs1gXXN84O/037kSBx7TZ5y6dB3MYVXhRZdo+rsg0SDc2k FiTkLvBByFrsbCTYWKQ8PGTtzzaETMOMWYIaCsATA0Ey9ruuoc+ilTIVNkLOLGxps34H3f32 T/ihAgzga8Cy/EC0aqT9ErCxTmro/DhUgcw7x7/QmGh4wV2dYOhIYev7DDmAe1oKY+YShyLu igCks3HtuQWV8jTxGqKXfkHG6yv67CdKjrAjFVzHp4nsTOw53qkeoMW6zZ7TKt0Dvs5lfbSS Be7kWtsCFV7YhNGsYcfj1qNNvkX
  • Ironport-hdrordr: A9a23:nnrXq6p6dQCV+uvgG6wXJvgaV5tKLNV00zEX/kB9WHVpm5Oj+v xGzc5w6farsl0ssREb9uxo9pPwJE800aQFmbX5XI3SJTUO3VHFEGgM1+vfKlHbak7DH6tmpN xdmstFeaHN5DpB/KHHCWCDer5PoeVvsprY49s2p00dMD2CAJsQizuRZDzrcHGfE2J9dOAE/d enl7x6T33KQwVmUu2LQl0+G8TTrdzCk5zrJTYAGh4c8QGLyR+49bLgFBCc/xEGFxdC260r/2 TpmxHwovzLiYDw9jbsk0voq7hGktrozdVOQOSKl8guMz3pziq4eYh7XLWGnTYt5MWi8kwjnt Xgqwope+5z93TSVGeopgaF4Xiq7B8er1vZjXOIi3rqpsL0ABo8Fsp6nIpcNj/U8VApst1Q2L 9CmzvxjeseMTrw2ADGo/TYXRBjkUS55VIkjO4olnRaFa8TcqVYo4Az9F5cVL0AACX5woY6F/ QGNrCU2N9mNXehK1zJtGhmx9KhGlw1Axe9W0AH/veY1jBH9UoJuncw9Yg6pDMt5Zg9Q55L66 DvKaJzjoxDSccQcOZUGPoBadHfMB2CfTv8dEapZXj3HqAOPHzA77Tt5q8u2e2scJsUiLMvhZ X6Vk9Cv2JaQTOgNSS35uwKzvnxehT/Ydy0ofsupaSR+4eMCIYDCBfzCWzHyKCb0rAi6s6yYY fABHsZOY6mEYLUI/c54+TPYegsFZAgarxqhj8aYSP7niuZEPycisXrNNDuGZHKLREIHkvCP1 prZkmBGCwH1DHnZkPF
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Sep 28, 2023 at 09:16:20AM +0200, Jan Beulich wrote:
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, add the necessary fork handling (with the
> backing function yet to be filled in).
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v3: Extend comment.
> 
> --- 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;
> +        }

I'm still unsure why map_guest_area() shouldn't be able to deal with a
forked child needing the page to be mapped.  What happens when a
forked child executes the hypercall to map such areas against not yet
populated gfns?

Shouldn't map_guest_area() be capable of handling those calls and
populating on demand?

> +        else if ( p2mt != p2m_ram_rw )
> +            return -EBUSY;
> +
> +        /*
> +         * Map the area into the guest. For simplicity specify the entire 
> range
> +         * up to the end of the page: All the function uses it for is to 
> check
> +         * that the range doesn't cross page boundaries. Having the area 
> mapped
> +         * in the original domain implies that it fits there and therefore 
> will
> +         * also fit in the clone.
> +         */
> +        offset = PAGE_OFFSET(d_area->map);
> +        ret = map_guest_area(cd_vcpu, gfn_to_gaddr(gfn) + offset,
> +                             PAGE_SIZE - offset, cd_area, NULL);
> +        if ( ret )
> +            return ret;
> +    }
> +    else
> +        cd_mfn = page_to_mfn(cd_area->pg);
> +
> +    copy_domain_page(cd_mfn, d_mfn);

I think the page copy should be done only once, when the page is
populated on the child p2m.  Otherwise areas smaller than a page size
(like vpcu_time_info_t) that share the same page will get multiple
copies of the same data for no reason.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.