Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752160AbbGMWGN (ORCPT ); Mon, 13 Jul 2015 18:06:13 -0400 Received: from smtp.citrix.com ([66.165.176.89]:46159 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751702AbbGMWGL (ORCPT ); Mon, 13 Jul 2015 18:06:11 -0400 X-IronPort-AV: E=Sophos;i="5.15,466,1432598400"; d="scan'208";a="280617161" Message-ID: <55A43638.4030503@citrix.com> Date: Tue, 14 Jul 2015 00:05:44 +0200 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Boris Ostrovsky , CC: , , , , "Konrad Rzeszutek Wilk" , David Vrabel Subject: Re: [PATCH v2 19/20] xen/privcmd: Add support for Linux 64KB page granularity References: <1436474552-31789-1-git-send-email-julien.grall@citrix.com> <1436474552-31789-20-git-send-email-julien.grall@citrix.com> <55A41BE4.3080104@oracle.com> In-Reply-To: <55A41BE4.3080104@oracle.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2292 Lines: 71 Hi Boris, On 13/07/2015 22:13, Boris Ostrovsky wrote: > On 07/09/2015 04:42 PM, Julien Grall wrote: >> - >> struct remap_data { >> xen_pfn_t *fgmfn; /* foreign domain's gmfn */ >> + xen_pfn_t *efgmfn; /* pointer to the end of the fgmfn array */ > > It might be better to keep size of fgmfn array instead. It would means to have an other variable to check that we are at the end the array. What about a variable which will be decremented? >> >> +static int unmap_gfn(struct page *page, unsigned long pfn, void *data) >> +{ >> + int *nr = data; >> + struct xen_remove_from_physmap xrp; >> + >> + /* The Linux Page may not have been fully mapped to Xen */ >> + if (!*nr) >> + return 0; >> + >> + xrp.domid = DOMID_SELF; >> + xrp.gpfn = pfn; >> + (void)HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); >> + >> + (*nr)--; >> + >> + return 0; >> +} >> + >> int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma, >> int nr, struct page **pages) >> { >> int i; >> + int nr_page = round_up(nr, XEN_PFN_PER_PAGE); >> - for (i = 0; i < nr; i++) { >> - struct xen_remove_from_physmap xrp; >> - unsigned long pfn; >> + for (i = 0; i < nr_page; i++) { >> + /* unmap_gfn guarantees ret == 0 */ >> + BUG_ON(xen_apply_to_page(pages[i], unmap_gfn, &nr)); > > > TBH, I am not sure how useful xen_apply_to_page() routine is. In this > patch especially, but also in others. It avoids an open loop in each place where it's needed (here, balloon...) which means another indentation layer. You can give a look it's quite ugly. Furthermore, the helper will avoid possible done by developers who are working on PV drivers on x86. If you see code where the MFN translation is done directly via virt_to_mfn or page_to_mfn... it will likely means that the code will be broking when 64KB page granularity will be in used. Though, there will still be some place where it's valid to use virt_to_mfn and page_to_mfn. Regards, -- Julien Grall -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/