xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>,
	"wl@xen.org" <wl@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Grall, Julien" <jgrall@amazon.com>,
	"Xia, Hongyan" <hongyxia@amazon.com>
Subject: Re: [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables
Date: Mon, 27 Jan 2020 15:43:12 +0100	[thread overview]
Message-ID: <1d38a17c-9b6b-a423-1326-33e24c583393@suse.com> (raw)
In-Reply-To: <dd3836c12457a92af545651b09acf910c2071bcf.camel@amazon.com>

On 27.01.2020 15:33, Xia, Hongyan wrote:
> On Thu, 2020-01-16 at 13:04 +0100, Jan Beulich wrote:
>> ...
>>
>>> +void free_xen_pagetable(void *v)
>>> +{
>>> +    mfn_t mfn = v ? virt_to_mfn(v) : INVALID_MFN;
>>> +
>>> +    if ( system_state != SYS_STATE_early_boot )
>>> +        free_xen_pagetable_new(mfn);
>>
>> The condition is (partly) redundant with what
>> free_xen_pagetable_new() does. Therefore I'd like to ask that
>> either the if() be dropped here, or be completed by also
>> checking v to be non-NULL, at which point this would likely
>> become just
>>
>> void free_xen_pagetable(void *v)
>> {
>>     if ( v && system_state != SYS_STATE_early_boot )
>>         free_xen_pagetable_new(virt_to_mfn(v));
>> }
> 
> You are right. Will change in the next revision.
> 
>>> +/* v can point to an entry within a table or be NULL */
>>> +void unmap_xen_pagetable(const void *v)
>>
>> Why "entry" in the comment?
> 
> I think the comment originally meant pointing to the entry in its
> parent table, which then meant pointing to this table. It's a bit
> confusing. Will reword.
> 
> Reflecting back to your comment in v3 about whether the new Xen page
> table mapping APIs (map/unmap_xen_pagetable) are really necessary, I
> agree in the end they will just do the same thing as
> map/unmap_domain_page, although one thing is that the latter suggests
> it is trying to map a `domain' page, whose definition probably does not
> include Xen page tables, so the name could be a bit confusing (well, we
> could argue that Xen page tables are just idle `domain' pages so the
> name still holds). If we are happy with using map_domain_page on Xen
> PTE tables then I am okay with dropping the new mapping APIs and only
> include the new alloc APIs.

Anyone on the To: list - opinions?

Thanks, Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-27 14:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 12:06 [Xen-devel] [PATCH v5 0/7] Add alternative API for XEN PTEs Hongyan Xia
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 1/7] x86: move some xen mm function declarations Hongyan Xia
2020-01-07 12:13   ` Wei Liu
2020-01-07 13:09     ` Jan Beulich
2020-01-07 13:37       ` Wei Liu
2020-01-07 13:48       ` Xia, Hongyan
2020-01-07 14:03         ` Wei Liu
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables Hongyan Xia
2020-01-16 12:04   ` Jan Beulich
2020-01-27 14:33     ` Xia, Hongyan
2020-01-27 14:43       ` Jan Beulich [this message]
2020-01-27 15:07         ` Xia, Hongyan
2020-01-27 17:13           ` George Dunlap
2020-01-27 17:51         ` Wei Liu
2020-01-27 17:49     ` Wei Liu
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 3/7] x86/mm: introduce l{1, 2}t local variables to map_pages_to_xen Hongyan Xia
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 4/7] x86/mm: introduce l{1, 2}t local variables to modify_xen_mappings Hongyan Xia
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 5/7] x86/mm: map_pages_to_xen would better have one exit path Hongyan Xia
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 6/7] x86/mm: make sure there is one exit path for modify_xen_mappings Hongyan Xia
2020-01-07 12:06 ` [Xen-devel] [PATCH v5 7/7] x86/mm: change pl*e to l*t in virt_to_xen_l*e Hongyan Xia

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=1d38a17c-9b6b-a423-1326-33e24c583393@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=hongyxia@amazon.com \
    --cc=jgrall@amazon.com \
    --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).