Re: [PATCH v2 05/11] tools/foreignmem: Support querying the size of a resource

[Andrew Cooper <amc96@xxxxxxxxx>]

On 11/01/2021 10:50, Roger Pau Monné wrote:
> On Fri, Jan 08, 2021 at 05:52:36PM +0000, Andrew Cooper wrote:
>> 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.
> I think the following patch should allow you to fetch the resource
> size from Linux privcmd driver by doing an ioctl with addr = 0 and num
> = 0. I've just build tested it, but I haven't tried exercising the
> code.
>
> Roger.
> ---8<---
> From 5d717c7b9ad3561ed0b17e7c5cf76b7c9fb536db Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Date: Mon, 11 Jan 2021 10:38:59 +0100
> Subject: [PATCH] xen/privcmd: allow fetching resource sizes
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
> addr = 0 in order to fetch the size of a specific resource.
>
> Add a shortcut to the default map resource path, since fetching the
> size requires no address to be passed in, and thus no VMA to setup.
>
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

> ---
> NB: fetching the size of a resource shouldn't trigger an hypercall
> preemption, and hence I've dropped the preempt indications.

Yeah - that's fine.  Querying the size isn't ever going to turn into a
long running operation from the guest's point of view.

I'll submit the matching patch for libxenforeignmem.

~Andrew