All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.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: Tue, 9 Dec 2025 12:34:42 +0100	[thread overview]
Message-ID: <aTgJUvqTIQRc66L_@Mac.lan> (raw)
In-Reply-To: <b03a8039-e4b3-42ff-9781-031bf68ccb72@suse.com>

On Mon, Dec 08, 2025 at 11:48:00AM +0100, Jan Beulich wrote:
> 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.

Redundancy is one of the aspects, the other being IMO code more prone
to errors.  Having to do all this non-trivial extra work after a call
to set a p2m entry, both in the success and failure cases, seems
likely that it will be forgotten or incorrectly implemented by some
of the callers.

It's you doing the work to fix this, so I'm not going to insist.  It
seems a lot of extra complexity duplicated across multiple callers.

FWIW, it would be easier to understand if we had the logic to mark
pages as dirty in a single place, rather than scattered around
different callers that do p2m modifications.  For the time being I'm
fine with doing as you propose, but long term we should see about
cleaning this code IMO.

> Furthermore p2m_entry_modify() also isn't really suitable: We don't
> know the GFN there.

For one of the callers there's the GFN in context.  For the EPT caller
it will likely require some plumbing.

> >> --- 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.

Sorry, I now realize.  paging_mark_dirty() takes a plain MFN, while
paging_mark_pfn_dirty() takes a PFN.

Thanks, Roger.


  reply	other threads:[~2025-12-09 11:35 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
2025-12-09 11:34       ` Roger Pau Monné [this message]
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=aTgJUvqTIQRc66L_@Mac.lan \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.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.