From patchwork Fri Sep 27 16:09:51 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 2955831 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 835C1BFF0B for ; Fri, 27 Sep 2013 16:12:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 533672016D for ; Fri, 27 Sep 2013 16:12:37 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 006C420160 for ; Fri, 27 Sep 2013 16:12:35 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VPae2-00089V-0u; Fri, 27 Sep 2013 16:11:54 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VPadq-0001bT-J4; Fri, 27 Sep 2013 16:11:42 +0000 Received: from smtp02.citrix.com ([66.165.176.63]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VPadO-0001Vy-52 for linux-arm-kernel@lists.infradead.org; Fri, 27 Sep 2013 16:11:15 +0000 X-IronPort-AV: E=Sophos;i="4.90,994,1371081600"; d="scan'208";a="55582476" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 27 Sep 2013 16:10:52 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Fri, 27 Sep 2013 12:10:51 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1VPacw-0002hO-IK; Fri, 27 Sep 2013 17:10:46 +0100 From: Stefano Stabellini To: Subject: [PATCH v6 03/19] xen: introduce XENMEM_exchange_and_pin and XENMEM_unpin Date: Fri, 27 Sep 2013 17:09:51 +0100 Message-ID: <1380298207-29151-3-git-send-email-stefano.stabellini@eu.citrix.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: References: MIME-Version: 1.0 X-DLP: MIA1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130927_121114_359495_1315491E X-CRM114-Status: GOOD ( 18.96 ) X-Spam-Score: -5.0 (-----) Cc: Ian.Campbell@citrix.com, Stefano Stabellini , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, konrad.wilk@oracle.com X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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. Reviewed-by: Konrad Rzeszutek Wilk --- 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__ */