[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.
|