From 9ed257d1d1c65dbe5a08f207e5106e98384e1860 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Fri, 15 Jan 2016 13:23:40 +0000 Subject: xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxenforeignmemory which provides access to privileged foreign mappings and which will provide an interface equivalent to xc_map_foreign_{pages,bulk}. In preparation for this switch all uses of xc_map_foreign_range to xc_map_foreign_pages. This is trivial because size was always XC_PAGE_SIZE so the necessary adjustments are trivial: * Pass &mfn (an array of length 1) instead of mfn. The function takes a pointer to const, so there is no possibily of mfn changing due to this change. * Pass nr_pages=1 instead of size=XC_PAGE_SIZE There is one wrinkle in xen_console.c:con_initialise() where con->ring_ref is an int but can in some code paths (when !xendev->dev) be treated as an mfn. I think this is an existing latent truncation hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g. amd64, both arm* variants). I'm unsure under what circumstances xendev->dev can be NULL or if anything elsewhere ensures the value fits into an int. For now I just use a temporary xen_pfn_t to in effect upcast the pointer from int* to xen_pfn_t*. In xenfb.c:common_bind we now explicitly launder the mfn into a xen_pfn_t, so it has the correct type to be passed to xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86. Signed-off-by: Ian Campbell Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/display/xenfb.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) (limited to 'hw/display') diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index 8eb3046..aa38803 100644 --- a/hw/display/xenfb.c +++ b/hw/display/xenfb.c @@ -95,23 +95,24 @@ struct XenFB { static int common_bind(struct common *c) { - uint64_t mfn; + uint64_t val; + xen_pfn_t mfn; - if (xenstore_read_fe_uint64(&c->xendev, "page-ref", &mfn) == -1) + if (xenstore_read_fe_uint64(&c->xendev, "page-ref", &val) == -1) return -1; - assert(mfn == (xen_pfn_t)mfn); + mfn = (xen_pfn_t)val; + assert(val == mfn); if (xenstore_read_fe_int(&c->xendev, "event-channel", &c->xendev.remote_port) == -1) return -1; - c->page = xc_map_foreign_range(xen_xc, c->xendev.dom, - XC_PAGE_SIZE, - PROT_READ | PROT_WRITE, mfn); + c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom, + PROT_READ | PROT_WRITE, &mfn, 1); if (c->page == NULL) return -1; xen_be_bind_evtchn(&c->xendev); - xen_be_printf(&c->xendev, 1, "ring mfn %"PRIx64", remote-port %d, local-port %d\n", + xen_be_printf(&c->xendev, 1, "ring mfn %"PRI_xen_pfn", remote-port %d, local-port %d\n", mfn, c->xendev.remote_port, c->xendev.local_port); return 0; -- cgit v1.1 From e0cb42ae4bc4438ba4ec0760df2d830b8759b255 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Fri, 15 Jan 2016 13:23:41 +0000 Subject: xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API. In Xen 4.7 we are refactoring parts libxenctrl into a number of separate libraries which will provide backward and forward API and ABI compatiblity. One such library will be libxenforeignmemory which provides access to privileged foreign mappings and which will provide an interface equivalent to xc_map_foreign_{pages,bulk}. The new xenforeignmemory_map() function behaves like xc_map_foreign_pages() when the err argument is NULL and like xc_map_foreign_bulk() when err is non-NULL, which maps into the shim here onto checking err == NULL and calling the appropriate old function. Note that xenforeignmemory_map() takes the number of pages before the arrays themselves, in order to support potentially future use of variable-length-arrays in the prototype (in the future, when Xen's baseline toolchain requirements are new enough to ensure VLAs are supported). In preparation for adding support for libxenforeignmemory add support to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to switch to using the new API. These shims will disappear for versions of Xen which include libxenforeignmemory. Since libxenforeignmemory will have its own handle type but for <= 4.6 the functionality is provided by using a libxenctrl handle we introduce a new global xen_fmem alongside the existing xen_xc. In fact we make xen_fmem a pointer to the existing xen_xc, which then works correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle is a pointer). In the latter case xen_fmem is actually a double indirect pointer, but it all falls out in the wash. Unlike libxenctrl libxenforeignmemory has an explicit unmap function, rather than just specifying that munmap should be used, so the unmap paths are updated to use xenforeignmemory_unmap, which is a shim for munmap on these versions of xen. The mappings in xen-hvm.c do not appear to be unmapped (which makes sense for a qemu-dm process) In fb_disconnect this results in a change from simply mmap over the existing mapping (with an implicit munmap) to expliclty unmapping with xenforeignmemory_unmap and then mapping the required anonymous memory in the same hole. I don't think this is a problem since any other thread which was racily touching this region would already be running the risk of hitting the mapping halfway through the call. If this is thought to be a problem then we could consider adding an extra API to the libxenforeignmemory interface to replace a foreign mapping with anonymous shared memory, but I'd prefer not to. Signed-off-by: Ian Campbell Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/display/xenfb.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'hw/display') diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index aa38803..1676660 100644 --- a/hw/display/xenfb.c +++ b/hw/display/xenfb.c @@ -106,8 +106,8 @@ static int common_bind(struct common *c) if (xenstore_read_fe_int(&c->xendev, "event-channel", &c->xendev.remote_port) == -1) return -1; - c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom, - PROT_READ | PROT_WRITE, &mfn, 1); + c->page = xenforeignmemory_map(xen_fmem, c->xendev.dom, + PROT_READ | PROT_WRITE, 1, &mfn, NULL); if (c->page == NULL) return -1; @@ -122,7 +122,7 @@ static void common_unbind(struct common *c) { xen_be_unbind_evtchn(&c->xendev); if (c->page) { - munmap(c->page, XC_PAGE_SIZE); + xenforeignmemory_unmap(xen_fmem, c->page, 1); c->page = NULL; } } @@ -495,15 +495,15 @@ static int xenfb_map_fb(struct XenFB *xenfb) fbmfns = g_malloc0(sizeof(xen_pfn_t) * xenfb->fbpages); xenfb_copy_mfns(mode, n_fbdirs, pgmfns, pd); - map = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom, - PROT_READ, pgmfns, n_fbdirs); + map = xenforeignmemory_map(xen_fmem, xenfb->c.xendev.dom, + PROT_READ, n_fbdirs, pgmfns, NULL); if (map == NULL) goto out; xenfb_copy_mfns(mode, xenfb->fbpages, fbmfns, map); - munmap(map, n_fbdirs * XC_PAGE_SIZE); + xenforeignmemory_unmap(xen_fmem, map, n_fbdirs); - xenfb->pixels = xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom, - PROT_READ, fbmfns, xenfb->fbpages); + xenfb->pixels = xenforeignmemory_map(xen_fmem, xenfb->c.xendev.dom, + PROT_READ, xenfb->fbpages, fbmfns, NULL); if (xenfb->pixels == NULL) goto out; @@ -913,6 +913,7 @@ static void fb_disconnect(struct XenDevice *xendev) * Replacing the framebuffer with anonymous shared memory * instead. This releases the guest pages and keeps qemu happy. */ + xenforeignmemory_unmap(xen_fmem, fb->pixels, fb->fbpages); fb->pixels = mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0); -- cgit v1.1