lkml.org 
[lkml]   [2013]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 03/19] xen: introduce XENMEM_exchange_and_pin and XENMEM_unpin
On Fri, Sep 27, 2013 at 05:09:51PM +0100, Stefano Stabellini wrote:
> XENMEM_exchange can't be used by autotranslate guests because of two
> severe limitations:
>
> - it does not copy back the mfns into the out field for autotranslate
> guests;
>
> - it does not guarantee that the hypervisor won't change the p2m
> mappings for the exchanged pages while the guest is using them. Xen
> never promises to keep the p2m mapping stable for autotranslate guests
> in general. In practice it won't happen unless one uses uncommon
> features like memory sharing or paging.
>
> To overcome these problems I am introducing two new hypercalls.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
>
> Changes in v6:
> - update the comments and the hypercalls structures.
>
> Changes in v5:
> - better comment for XENMEM_exchange_and_pin return codes;
>
> Changes in v4:
> - rename XENMEM_get_dma_buf to XENMEM_exchange_and_pin;
> - rename XENMEM_put_dma_buf to XENMEM_unpin;
> - improve the documentation of the new hypercalls;
> - add a note about out.address_bits for XENMEM_exchange.
> ---
> include/xen/interface/memory.h | 51 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 2ecfe4f..49db252 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -66,6 +66,9 @@ struct xen_memory_exchange {
> /*
> * [IN] Details of memory extents to be exchanged (GMFN bases).
> * Note that @in.address_bits is ignored and unused.
> + * @out.address_bits contains the maximum number of bits addressable
> + * by the caller. The addresses of the newly allocated pages have to
> + * meet this restriction.
> */
> struct xen_memory_reservation in;
>
> @@ -263,4 +266,52 @@ struct xen_remove_from_physmap {
> };
> DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
>
> +/*
> + * This hypercall is similar to XENMEM_exchange: it takes the same
> + * struct as an argument and it exchanges the pages passed in with a new
> + * set of pages. The new pages are going to be "pinned": it's guaranteed
> + * that their p2m mapping won't be changed until explicitly "unpinned".
> + * Only normal guest r/w memory can be pinned: no granted pages or
> + * ballooned pages.
> + * If return code is zero then @out.extent_list provides the frame
> + * numbers of the newly-allocated memory.
> + * On X86 the frame numbers are machine frame numbers (mfns).
> + * On ARMv7 and ARMv8 the frame numbers are machine frame numbers (mfns).
> + * Returns zero on complete success, otherwise a negative error code.
> + * The most common error codes are:
> + * -ENOSYS if not implemented
> + * -EPERM if the domain is not privileged for this operation
> + * -EBUSY if the page is already pinned
> + * -EFAULT if an internal error occurs
> + * On complete success then always @nr_exchanged == @in.nr_extents. On
> + * partial success @nr_exchanged indicates how much work was done and a
> + * negative error code is returned.
> + */
> +#define XENMEM_exchange_and_pin 26
> +
> +/*
> + * XENMEM_unpin unpins a set of pages, previously pinned by
> + * XENMEM_exchange_and_pin. After this call the p2m mapping of the pages can
> + * be transparently changed by the hypervisor, as usual. The pages are
> + * still accessible from the guest.
> + */
> +#define XENMEM_unpin 27
> +struct xen_unpin {
> + /*
> + * [IN] Details of memory extents to be unpinned (GMFN bases).
> + * Note that @in.address_bits is ignored and unused.
> + */
> + struct xen_memory_reservation in;
> + /*
> + * [OUT] Number of input extents that were successfully unpinned.
> + * 1. The first @nr_unpinned input extents were successfully
> + * unpinned.
> + * 2. All other input extents are untouched.
> + * 3. If not all input extents are unpinned then the return code of this
> + * command will be non-zero.
> + */
> + xen_ulong_t nr_unpinned;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_unpin);
> +
> #endif /* __XEN_PUBLIC_MEMORY_H__ */
> --
> 1.7.2.5
>


\
 
 \ /
  Last update: 2013-09-30 17:01    [W:0.255 / U:7.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site