[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Tiejun Chen writes ("[Xen-devel] [v5][PATCH 01/16] xen: introduce 
> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.