Re: [Xen-devel] [v5][PATCH 01/16] xen: introduce XENMEM_reserved_device_memory_map

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Tiejun Chen writes ("[Xen-devel] [v5][PATCH 01/16] xen: introduce 
XENMEM_reserved_device_memory_map"):
> From: Jan Beulich <jbeulich@xxxxxxxx>
> 
> This is a prerequisite for punching holes into HVM and PVH guests' P2M
> to allow passing through devices that are associated with (on VT-d)
> RMRRs.
...

This function:

> +++ b/xen/common/compat/memory.c
...
> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                      u32 id, void *ctxt)

is remarkably similar to this function

> +++ b/xen/common/memory.c
...
> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
> +                                      u32 id, void *ctxt)


Is this usual in hypervisor code ?  It may be that this is the general
approach in compat code and that any cure would be worse than the
disease, but I found it very striking.


> +/*
> + * With some legacy devices, certain guest-physical addresses cannot safely
> + * be used for other purposes, e.g. to map guest RAM.  This hypercall
> + * enumerates those regions so the toolstack can avoid using them.
...
> +    /* IN/OUT */
> +    unsigned int    nr_entries;

Perhaps I am missing something but I can't find any API documentation
for the return value and error returns from this new hypercall.


Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel