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

Re: [PATCH 01/16] x86/P2M: rename p2m_remove_page()


  • To: George Dunlap <dunlapg@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 7 Feb 2022 10:20:32 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NWVIcuAI03ir6QzaPqtvoKoNBC94D5lPp1xYNb/0onk=; b=mUM/XoffOR4gLUEBn9snH9yDiSjJA1vIvZr7WVbrD84f0DJ6rKbpCK39A2XTJ7URwBGB73ZuccM7HX9ujXWfix25Oiq9H2ji1URyhHPhwF5b4vcQ9fFkBVRcqNAbREPo0u0wPLBoiYaoii3nz///uQ2GYpGrlCqCAZSG7iPMcQ4oUvVDLLflCtjZhewPdjfFq5GHz1oXL8LqnGjoepx8d9oD6tfu6XRHGoNsJAfjtsbfFT/T31QJYOLg9Gpcq8iXbJ5ZKrvisPUISzJnGC3CF4TADJoE1qK9dftZWHegwFtgnluyeIm+/v0PbEvBKWKMucCx60SbHfkmKQYVmny8nw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iMIkYtAS2IMwZRXFvkB0fs39kZA6AwZSIbN1RGuB5yO4/MkV7sz4v2diXYQuYjlMRgRRtUewAnabW7FIlt5azQzRM3T4TEptnZ9/Hn1cb8+aG20jSp7k6LOGg7JR4G3pO0DUFoVI9HxJABzpwkWhMqh7nlfqKbko0oTF0ATWbjA+KBvp3cgqXdgCNegDgbNgxelz8WlUs5uy62DnQA7Gp/qIRWEwVxp1kJuOqbvb6ZXCZj+a5/qqvNNfI28WJC+kLpqDrInTmixgT1XDw+Js2snZzxOI1bUt3w7pu5EPdxhesbd2BgMpDzq5CqMlyyorJUPQfR7ga010P8WsUutAoQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
  • Delivery-date: Mon, 07 Feb 2022 09:20:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.02.2022 22:54, George Dunlap wrote:
> On Mon, Jul 5, 2021 at 5:05 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -788,8 +788,8 @@ void p2m_final_teardown(struct domain *d
>>  #ifdef CONFIG_HVM
>>
>>  static int __must_check
>> -p2m_remove_page(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
>> -                unsigned int page_order)
>> +p2m_remove_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
>> +                 unsigned int page_order)
>>
> 
> One question that's naturally raised for both this and the following patch
> is, what is the new naming "scheme" for these renamed functions, and how do
> they relate to the old scheme?
> 
> Overall it seems like the intention is that "guest_physmap_..." can be
> called on a domain which may be PV or HVM, while "p2m_..." should only be
> called on HVM domains.

Yes. I think by the end of the series all p2m_...() named functions
pertain to HVM domains only.

> There's also "..._entry" vs "..._page".  Is the p2m_remove_page /
> p2m_remove_entry distinction have a meaning, and is it the same meaning as
> guest_physmap_add_page / guest_physmap_add_entry?

In the next patch a pair p2m_{add,remove}_page() is introduced.
p2m_remove_entry() remains a static helper for the latter of the two,
assuming the GFN is already locked. I've used the "page" vs "entry" in
the names just like it was used prior to patch 2; I'd be happy to take
suggestions on what else could be used in place of "entry" (but I'd
like to stick to "page").

Jan




 


Rackspace

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