From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
Juergen Gross <jgross@suse.com>,
Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH v3 7/8] x86/mm: update log-dirty bitmap when manipulating P2M
Date: Mon, 8 Dec 2025 11:48:00 +0100 [thread overview]
Message-ID: <b03a8039-e4b3-42ff-9781-031bf68ccb72@suse.com> (raw)
In-Reply-To: <aTLjwbcm4fjwNJfb@Mac.lan>
On 05.12.2025 14:53, Roger Pau Monné wrote:
> On Tue, Apr 26, 2022 at 12:26:10PM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -549,7 +549,10 @@ p2m_remove_entry(struct p2m_domain *p2m,
>> {
>> p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0, NULL, NULL);
>> if ( !p2m_is_special(t) && !p2m_is_shared(t) )
>> + {
>> set_gpfn_from_mfn(mfn_x(mfn) + i, INVALID_M2P_ENTRY);
>> + paging_mark_pfn_clean(p2m->domain, _pfn(gfn_x(gfn) + i));
>> + }
>> }
>> }
>>
>> @@ -737,8 +740,11 @@ p2m_add_page(struct domain *d, gfn_t gfn
>> if ( !p2m_is_grant(t) )
>> {
>> for ( i = 0; i < (1UL << page_order); i++ )
>> + {
>> set_gpfn_from_mfn(mfn_x(mfn_add(mfn, i)),
>> gfn_x(gfn_add(gfn, i)));
>> + paging_mark_pfn_dirty(d, _pfn(gfn_x(gfn) + i));
>
> Have you considered placing the respective
> paging_mark_pfn_{clean,dirty}() calls in p2m_entry_modify()?
I didn't, but since you ask - I also don't think that's layering-wise
an appropriate place for them to live. Whether a page has to be
considered dirty needs determining elsewhere. No matter that ...
> There's a lot of repetition here with regard to handling the side
> effects of p2m changes that are forced into the callers, that could
> likely be contained inside of p2m_entry_modify() at first sight.
... this way there is some redundancy.
Furthermore p2m_entry_modify() also isn't really suitable: We don't
know the GFN there.
>> --- a/xen/arch/x86/include/asm/paging.h
>> +++ b/xen/arch/x86/include/asm/paging.h
>> @@ -165,8 +165,9 @@ void paging_log_dirty_init(struct domain
>>
>> /* mark a page as dirty */
>> void paging_mark_dirty(struct domain *d, mfn_t gmfn);
>> -/* mark a page as dirty with taking guest pfn as parameter */
>> +/* mark a page as dirty/clean with taking guest pfn as parameter */
>
> I think it would be clearer to use gfn here rather than "guest pfn",
> and the function parameter should be "gfn_t gfn".
For HVM I'd agree, but please see the one use for PV guests. As per
xen/mm.h gfn == mfn for them, i.e. we particularly mean PFN there.
Jan
next prev parent reply other threads:[~2025-12-08 10:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 10:20 [PATCH v3 0/8] x86: more or less log-dirty related improvements Jan Beulich
2022-04-26 10:22 ` [PATCH v3 1/8] libxenguest: short-circuit "all-dirty" handling Jan Beulich
2022-04-26 10:22 ` [PATCH v3 2/8] libxenguest: avoid allocating unused deferred-pages bitmap Jan Beulich
2022-04-26 10:23 ` [PATCH v3 3/8] libxenguest: guard against overflow from too large p2m when checkpointing Jan Beulich
2022-04-26 10:23 ` [PATCH v3 4/8] libxenguest: restrict PV guest size Jan Beulich
2022-04-26 10:24 ` [PATCH v3 5/8] libxenguest: deal with log-dirty op stats overflow Jan Beulich
2022-04-26 10:54 ` Andrew Cooper
2022-04-26 14:24 ` Jan Beulich
2022-04-26 10:25 ` [PATCH v3 6/8] x86/paging: supply more useful log-dirty page count Jan Beulich
2022-04-26 10:26 ` [PATCH v3 7/8] x86/mm: update log-dirty bitmap when manipulating P2M Jan Beulich
2025-12-05 13:53 ` Roger Pau Monné
2025-12-08 10:48 ` Jan Beulich [this message]
2025-12-09 11:34 ` Roger Pau Monné
2025-12-09 11:49 ` Jan Beulich
2025-12-10 9:01 ` Roger Pau Monné
2025-12-10 9:28 ` Jan Beulich
2025-12-10 9:42 ` Roger Pau Monné
2025-12-10 9:55 ` Jan Beulich
2025-12-10 9:57 ` Roger Pau Monné
2022-04-26 10:27 ` [PATCH v3 8/8] SUPPORT.md: write down restriction of 32-bit tool stacks Jan Beulich
2023-06-16 20:50 ` Julien Grall
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=b03a8039-e4b3-42ff-9781-031bf68ccb72@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jgross@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.