From: Jan Beulich <jbeulich@suse.com>
To: paul@xen.org
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 02/16] x86/P2M: introduce p2m_{add,remove}_page()
Date: Tue, 6 Jul 2021 09:05:54 +0200 [thread overview]
Message-ID: <c527a6a9-f747-4a52-c668-069afdc375ec@suse.com> (raw)
In-Reply-To: <04de95f8-313e-aef3-1cea-599d5526233b@xen.org>
On 05.07.2021 19:47, Paul Durrant wrote:
> On 05/07/2021 17:06, Jan Beulich wrote:
>> p2m_add_page() is simply a rename from guest_physmap_add_entry().
>> p2m_remove_page() then is its counterpart, despite rendering
>> guest_physmap_remove_page().
>
> Did some words get dropped in that second sentence? I can't really
> understand what it is saying.
Oops - this was meant to be "... a trivial wrapper".
>> This way callers can use suitable pairs of
>> functions (previously violated by hvm/grant_table.c).
>>
>> In HVM-specific code further avoid going through the guest_physmap_*()
>> layer, and instead use the two new/renamed functions directly.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>
> The code looks fine so...
>
> Reviewed-by: Paul Durrant <paul@xen.org>
Thanks.
Jan
next prev parent reply other threads:[~2021-07-06 7:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 16:03 [PATCH 00/16] x86/mm: large parts of P2M code and struct p2m_domain are HVM-only Jan Beulich
2021-07-05 16:05 ` Jan Beulich
2021-07-05 16:05 ` [PATCH 01/16] x86/P2M: rename p2m_remove_page() Jan Beulich
2022-02-04 21:54 ` George Dunlap
2022-02-07 9:20 ` Jan Beulich
2021-07-05 16:06 ` [PATCH 02/16] x86/P2M: introduce p2m_{add,remove}_page() Jan Beulich
2021-07-05 17:47 ` Paul Durrant
2021-07-06 7:05 ` Jan Beulich [this message]
2022-02-04 22:07 ` George Dunlap
2022-02-07 9:38 ` Jan Beulich
2022-02-07 15:49 ` George Dunlap
2021-07-05 16:06 ` [PATCH 03/16] x86/P2M: drop a few CONFIG_HVM Jan Beulich
2022-02-04 22:13 ` George Dunlap
2022-02-07 9:51 ` Jan Beulich
2021-07-05 16:07 ` [PATCH 04/16] x86/P2M: move map_domain_gfn() (again) Jan Beulich
2022-02-04 22:17 ` George Dunlap
2021-07-05 16:07 ` [PATCH 05/16] x86/mm: move guest_physmap_{add,remove}_page() Jan Beulich
2022-02-05 21:06 ` George Dunlap
2021-07-05 16:07 ` [PATCH 06/16] x86/mm: split set_identity_p2m_entry() into PV and HVM parts Jan Beulich
2022-02-05 21:09 ` George Dunlap
2021-07-05 16:09 ` [PATCH 07/16] x86/P2M: p2m_{alloc,free}_ptp() and p2m_alloc_table() are HVM-only Jan Beulich
2021-07-07 1:35 ` Tian, Kevin
2022-02-05 21:17 ` George Dunlap
2021-07-05 16:09 ` [PATCH 08/16] x86/P2M: PoD, altp2m, and nested-p2m " Jan Beulich
2022-02-05 21:29 ` George Dunlap
2022-02-07 10:11 ` Jan Beulich
2022-02-07 14:45 ` George Dunlap
2022-02-07 15:23 ` Jan Beulich
2021-07-05 16:10 ` [PATCH 09/16] x86/P2M: split out init/teardown functions Jan Beulich
2022-02-05 21:31 ` George Dunlap
2021-07-05 16:10 ` [PATCH 10/16] x86/P2M: p2m_get_page_from_gfn() is HVM-only Jan Beulich
2022-02-14 14:26 ` George Dunlap
2021-07-05 16:12 ` [PATCH 11/16] x86/P2M: derive a HVM-only variant from __get_gfn_type_access() Jan Beulich
2022-02-14 15:12 ` George Dunlap
2022-02-14 15:20 ` Jan Beulich
2021-07-05 16:12 ` [PATCH 12/16] x86/p2m: re-arrange {,__}put_gfn() Jan Beulich
2022-02-14 15:17 ` George Dunlap
2021-07-05 16:13 ` [PATCH 13/16] shr_pages field is MEM_SHARING-only Jan Beulich
2021-07-06 12:42 ` Tamas K Lengyel
2022-02-14 15:36 ` George Dunlap
2021-07-05 16:14 ` [PATCH 14/16] paged_pages field is MEM_PAGING-only Jan Beulich
2021-07-06 12:44 ` Tamas K Lengyel
2022-02-14 15:38 ` George Dunlap
2021-07-05 16:14 ` [PATCH 15/16] x86/P2M: p2m.c is HVM-only Jan Beulich
2022-02-14 15:39 ` George Dunlap
2021-07-05 16:15 ` [PATCH 16/16] x86/P2M: the majority for struct p2m_domain's fields are HVM-only Jan Beulich
2021-07-05 17:49 ` Paul Durrant
2022-02-14 15:51 ` George Dunlap
2022-02-14 16:07 ` Jan Beulich
2022-02-16 7:54 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c527a6a9-f747-4a52-c668-069afdc375ec@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).