On 22/09/2020 19:24, Andrew Cooper wrote: > diff --git a/tools/libs/foreignmemory/linux.c > b/tools/libs/foreignmemory/linux.c > index fe73d5ab72..eec089e232 100644 > --- a/tools/libs/foreignmemory/linux.c > +++ b/tools/libs/foreignmemory/linux.c > @@ -339,6 +342,39 @@ int osdep_xenforeignmemory_map_resource( > return 0; > } > > +int osdep_xenforeignmemory_resource_size( > + xenforeignmemory_handle *fmem, domid_t domid, unsigned int type, > + unsigned int id, unsigned long *nr_frames) > +{ > + int rc; > + struct xen_mem_acquire_resource *xmar = > + xencall_alloc_buffer(fmem->xcall, sizeof(*xmar)); > + > + if ( !xmar ) > + { > + PERROR("Could not bounce memory for acquire_resource hypercall"); > + return -1; > + } > + > + *xmar = (struct xen_mem_acquire_resource){ > + .domid = domid, > + .type = type, > + .id = id, > + }; > + > + rc = xencall2(fmem->xcall, __HYPERVISOR_memory_op, > + XENMEM_acquire_resource, (uintptr_t)xmar); > + if ( rc ) > + goto out; > + > + *nr_frames = xmar->nr_frames; > + > + out: > + xencall_free_buffer(fmem->xcall, xmar); > + > + return rc; > +}
Having talked this through with Roger, it's broken. In the meantime, foreignmem has gained acquire_resource on FreeBSD. Nothing in this osdep function is linux-specific, so it oughtn't to be osdep. However, its also not permitted to make hypercalls like this in restricted mode, and that isn't something we should be breaking. Amongst other things, it will prevent us from supporting >128 cpus, as Qemu needs updating to use this interface in due course. The only solution (which keeps restricted mode working) is to fix Linux's ioctl() to be able to understand size requests. This also avoids foreignmem needing to open a xencall handle which was fugly in the first place. This patch (well - a subset of it) will be needed to remain, to make a usable interface in userspace. ~Andrew