Received: by 10.213.65.68 with SMTP id h4csp2454235imn; Thu, 5 Apr 2018 15:35:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Yi5zvrX0rdefnoKvTZ7s11pDaP5DNM2R+o5hHtH0w4oakSokPKZK9OCnTB1WgwhkkN1tC X-Received: by 2002:a17:902:a981:: with SMTP id bh1-v6mr25228000plb.255.1522967715569; Thu, 05 Apr 2018 15:35:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522967715; cv=none; d=google.com; s=arc-20160816; b=cZkDkPdHAQWqt6Fu81eyC/5Lzq+8KGWp5JF55KWjf8qYMkiTDIm3Aes/MJizFKFqQf xURJMDMEvDtaXkmaB6XauLgwDWlBrZnHTSzP90f8pxESHDhG8DCaTZyO6be8vYjemnT4 GE3+UINnFMQv+h3JRVZ2u8C0snHIfuI5BhR5crbXMtYS0Jokh7QHfWywszNmGyt5SR22 OBxAQ7bU1IlnowxPavvmXEw3IGxDBNJF0I3/J0SYx0JXmW7WHeN8Podk3wP263QpEVIB paH919GBQIPsObII4rV0D/skKgFhzMaSbL5BNeNy2hXGDOwFtzrVdgLjyfSaB4/lKI6o LGGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject :dkim-signature:arc-authentication-results; bh=Kn9xkU/jjsjRNUZHdk/pDb5Ms/X4aBdbdohzQqIzgkg=; b=ijk7v0nem63iGJbWMl8F/YlnwFKAwI5DPUIN0v8VO0Gqz9d86B1Xvx8dFlrBDfCRUX IHQHisVaGq6+Dym6aJSm2HNmdjhos5o6WHx9I2MndfuGLqoCVf57BrJ1L6WVmv36qNEu sMWs+2DwNHZxCCz674qEuWUPwHZCFP6vW8r1x2FXAa+j5MB0oW4DdqJrvj5s2D1+Q9V9 w33Q0Lev5lQkHB1tNH+0JByx/cMA8ZAzOgjdsplaghcOFp+vfNX1NWNqslRpksYq7lQS cRA3kfFxkQCGb3ZWB6myAYujPLvmykueLlJWycwwiOlUIeix/keZHPiCfaTquhAid6uu clNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=N4TtOIHJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s13si6779389pfs.91.2018.04.05.15.35.01; Thu, 05 Apr 2018 15:35:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=N4TtOIHJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754129AbeDEWcD (ORCPT + 99 others); Thu, 5 Apr 2018 18:32:03 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:53314 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752666AbeDEWcB (ORCPT ); Thu, 5 Apr 2018 18:32:01 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w35M3mRI107422; Thu, 5 Apr 2018 22:31:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=Kn9xkU/jjsjRNUZHdk/pDb5Ms/X4aBdbdohzQqIzgkg=; b=N4TtOIHJclDQaqS0pK66uFVrqEg+lNxqH3zyEBm8ktAANQMYSvuHLOk0FnV9GEohY8UE q2M23iwgR2g3HSv+7syJzHpKbEGGY5o2SGActwcxzl3w6hTEroUc8p7JJ7Vmji/Xaw13 ED8vFetT/ShW9O5JzQqO+DcQ5aWxxba9NXh6JEfzRLTgXL3NREfCcsFNwZpzcZl9hTOq JpLlcNlIiIrI7+11XAIOUdtNpit4iSwaVcVU92rXxUoGy+yqC7QN0YzZmqKwYcUcnmPI qACJz0AdkXUxCqrYauUQXNsMsNraP7kFSuaw/EKwmDWu/kI7uMh/l9HlvWrskCE0XlVv tA== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2h5kc6aj2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 05 Apr 2018 22:31:39 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w35MVcO7001302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Apr 2018 22:31:38 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w35MVbet008396; Thu, 5 Apr 2018 22:31:37 GMT Received: from dhcp-burlington7-2nd-B-east-10-152-55-162.usdhcp.oraclecorp.com (/10.152.32.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Apr 2018 15:31:37 -0700 Subject: Re: [PATCH v2] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE To: Paul Durrant , x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar References: <20180405154249.33929-1-paul.durrant@citrix.com> From: Boris Ostrovsky Openpgp: preference=signencrypt Autocrypt: addr=boris.ostrovsky@oracle.com; prefer-encrypt=mutual; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <727b9efc-f448-2955-6a47-774de330bcd8@oracle.com> Date: Thu, 5 Apr 2018 18:33:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180405154249.33929-1-paul.durrant@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8854 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050224 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/2018 11:42 AM, Paul Durrant wrote: > My recent Xen patch series introduces a new HYPERVISOR_memory_op to > support direct priv-mapping of certain guest resources (such as ioreq > pages, used by emulators) by a tools domain, rather than having to access > such resources via the guest P2M. > > This patch adds the necessary infrastructure to the privcmd driver and > Xen MMU code to support direct resource mapping. > > NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now > allow a PV tools domain to map guest pages either by GFN or MFN, thus > the term 'mfn' has been swapped for 'pfn' in the lower layers of the > remap code. > > Signed-off-by: Paul Durrant > --- > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Thomas Gleixner > Cc: Ingo Molnar > > v2: > - Fix bug when mapping multiple pages of a resource Only a few nits below. > --- > arch/x86/xen/mmu.c | 50 +++++++++++----- > drivers/xen/privcmd.c | 130 +++++++++++++++++++++++++++++++++++++++++ > include/uapi/xen/privcmd.h | 11 ++++ > include/xen/interface/memory.h | 66 +++++++++++++++++++++ > include/xen/interface/xen.h | 7 ++- > include/xen/xen-ops.h | 24 +++++++- > 6 files changed, 270 insertions(+), 18 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index d33e7dbe3129..8453d7be415c 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -65,37 +65,42 @@ static void xen_flush_tlb_all(void) > #define REMAP_BATCH_SIZE 16 > > struct remap_data { > - xen_pfn_t *mfn; > + xen_pfn_t *pfn; > bool contiguous; > + bool no_translate; > pgprot_t prot; > struct mmu_update *mmu_update; > }; > > -static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, > +static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token, > unsigned long addr, void *data) > { > struct remap_data *rmd = data; > - pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot)); > + pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot)); > > /* If we have a contiguous range, just update the mfn itself, > else update pointer to be "next mfn". */ This probably also needs to be updated (and while at it, comment style fixed) > if (rmd->contiguous) > - (*rmd->mfn)++; > + (*rmd->pfn)++; > else > - rmd->mfn++; > + rmd->pfn++; > > - rmd->mmu_update->ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE; > + rmd->mmu_update->ptr = virt_to_machine(ptep).maddr; > + rmd->mmu_update->ptr |= rmd->no_translate ? > + MMU_PT_UPDATE_NO_TRANSLATE : > + MMU_NORMAL_PT_UPDATE; > rmd->mmu_update->val = pte_val_ma(pte); > rmd->mmu_update++; > > return 0; > } > > -static int do_remap_gfn(struct vm_area_struct *vma, > +static int do_remap_pfn(struct vm_area_struct *vma, > unsigned long addr, > - xen_pfn_t *gfn, int nr, > + xen_pfn_t *pfn, int nr, > int *err_ptr, pgprot_t prot, > - unsigned domid, > + unsigned int domid, > + bool no_translate, > struct page **pages) > { > int err = 0; > @@ -106,11 +111,12 @@ static int do_remap_gfn(struct vm_area_struct *vma, > > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO))); > > - rmd.mfn = gfn; > + rmd.pfn = pfn; > rmd.prot = prot; > /* We use the err_ptr to indicate if there we are doing a contiguous > * mapping or a discontigious mapping. */ Style. > rmd.contiguous = !err_ptr; > + rmd.no_translate = no_translate; > > while (nr) { > int index = 0; > @@ -121,7 +127,7 @@ static int do_remap_gfn(struct vm_area_struct *vma, > > rmd.mmu_update = mmu_update; > err = apply_to_page_range(vma->vm_mm, addr, range, > - remap_area_mfn_pte_fn, &rmd); > + remap_area_pfn_pte_fn, &rmd); > if (err) > goto out; > > @@ -175,7 +181,8 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma, > if (xen_feature(XENFEAT_auto_translated_physmap)) > return -EOPNOTSUPP; > > - return do_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid, pages); > + return do_remap_pfn(vma, addr, &gfn, nr, NULL, prot, domid, false, > + pages); > } > EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range); > > @@ -183,7 +190,7 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma, > unsigned long addr, > xen_pfn_t *gfn, int nr, > int *err_ptr, pgprot_t prot, > - unsigned domid, struct page **pages) > + unsigned int domid, struct page **pages) Is this really necessary? And if it is, then why are other routines (e.g. xen_remap_domain_gfn_range() above) not updated as well? > { > if (xen_feature(XENFEAT_auto_translated_physmap)) > return xen_xlate_remap_gfn_array(vma, addr, gfn, nr, err_ptr, > @@ -194,10 +201,25 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma, > * cause of "wrong memory was mapped in". > */ > BUG_ON(err_ptr == NULL); > - return do_remap_gfn(vma, addr, gfn, nr, err_ptr, prot, domid, pages); > + return do_remap_pfn(vma, addr, gfn, nr, err_ptr, prot, domid, > + false, pages); > } > EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array); > > +int xen_remap_domain_mfn_array(struct vm_area_struct *vma, > + unsigned long addr, > + xen_pfn_t *mfn, int nr, > + int *err_ptr, pgprot_t prot, > + unsigned int domid, struct page **pages) > +{ > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return -EOPNOTSUPP; > + > + return do_remap_pfn(vma, addr, mfn, nr, err_ptr, prot, domid, > + true, pages); > +} > +EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_array); > + > /* Returns: 0 success */ > int xen_unmap_domain_gfn_range(struct vm_area_struct *vma, > int nr, struct page **pages) > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index 1c909183c42a..cca809a204ab 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -722,6 +723,131 @@ static long privcmd_ioctl_restrict(struct file *file, void __user *udata) > return 0; > } > > +struct remap_pfn { > + struct mm_struct *mm; > + struct page **pages; > + pgprot_t prot; > + unsigned long i; > +}; > + > +static int remap_pfn(pte_t *ptep, pgtable_t token, unsigned long addr, Maybe remap_pfn_fn (to avoid name shadowing)? > + void *data) > +{ > + struct remap_pfn *r = data; > + struct page *page = r->pages[r->i]; > + pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), r->prot)); > + > + set_pte_at(r->mm, addr, ptep, pte); > + r->i++; > + > + return 0; > +} > + > +static long privcmd_ioctl_mmap_resource(struct file *file, void __user *udata) > +{ > + struct privcmd_data *data = file->private_data; > + struct mm_struct *mm = current->mm; > + struct vm_area_struct *vma; > + struct privcmd_mmap_resource kdata; > + xen_pfn_t *pfns = NULL; > + struct xen_mem_acquire_resource xdata; > + int rc; > + > + if (copy_from_user(&kdata, udata, sizeof(kdata))) > + return -EFAULT; > + > + /* If restriction is in place, check the domid matches */ > + if (data->domid != DOMID_INVALID && data->domid != kdata.dom) > + return -EPERM; > + > + down_write(&mm->mmap_sem); > + > + vma = find_vma(mm, kdata.addr); > + if (!vma || vma->vm_ops != &privcmd_vm_ops) { > + rc = -EINVAL; > + goto out; > + } > + > + pfns = kcalloc(kdata.num, sizeof(*pfns), GFP_KERNEL); > + if (!pfns) { > + rc = -ENOMEM; > + goto out; > + } > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + struct page **pages; > + unsigned int i; > + > + rc = alloc_empty_pages(vma, kdata.num); > + if (rc < 0) > + goto out; > + > + pages = vma->vm_private_data; > + for (i = 0; i < kdata.num; i++) { > + pfns[i] = page_to_pfn(pages[i]); > + pr_info("pfn[%u] = %p\n", i, (void *)pfns[i]); > + } > + } else > + vma->vm_private_data = PRIV_VMA_LOCKED; > + > + memset(&xdata, 0, sizeof(xdata)); > + xdata.domid = kdata.dom; > + xdata.type = kdata.type; > + xdata.id = kdata.id; > + xdata.frame = kdata.idx; > + xdata.nr_frames = kdata.num; > + set_xen_guest_handle(xdata.frame_list, pfns); > + > + xen_preemptible_hcall_begin(); > + rc = HYPERVISOR_memory_op(XENMEM_acquire_resource, &xdata); > + xen_preemptible_hcall_end(); > + > + if (rc) > + goto out; > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + struct remap_pfn r = { > + .mm = vma->vm_mm, > + .pages = vma->vm_private_data, > + .prot = vma->vm_page_prot, > + }; > + > + rc = apply_to_page_range(r.mm, kdata.addr, > + kdata.num << PAGE_SHIFT, > + remap_pfn, &r); > + } else { > + unsigned int domid = > + (xdata.flags & XENMEM_rsrc_acq_caller_owned) ? > + DOMID_SELF : kdata.dom; > + int num; > + > + num = xen_remap_domain_mfn_array(vma, > + kdata.addr & PAGE_MASK, > + pfns, kdata.num, (int *)pfns, > + vma->vm_page_prot, > + domid, > + vma->vm_private_data); > + if (num < 0) > + rc = num; > + else if (num != kdata.num) { > + unsigned int i; > + > + for (i = 0; i < num; i++) { > + rc = pfns[i]; > + if (rc < 0) > + break; > + } > + } else > + rc = 0; > + } > + > +out: > + kfree(pfns); > + > + up_write(&mm->mmap_sem); I'd swap these two. -boris