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

Re: [PATCH v3 7/8] x86/mm: update log-dirty bitmap when manipulating P2M


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 5 Dec 2025 14:53:05 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=oXfCLneTDE/wGmjOVHRM+sWugPFQ+/KQZJeE3ZuLfwI=; b=C/PZ5A/gpG3lBfxgk9dVfpMIFdBrId0Q7CUTpBffSxlQ3/I8dySGZBS+gBle/TtGfL7rQc6JXMzOmZDu3VuUeFDJlguQhEjtLfKEBCf/MmXhUC2E3wz6UtpSGhqL4Q0pikrr3nYeHw/2ImI1IFjZ4F2wCfRxiqCwCSROvO7gaxIv2w+4gjNDZ1qgCwDhRxEIeJlto5tyFW6iXKiX3cgBqut8NDk8gqwmxUar8ZNNtcVIL6ayOKI6lUIhNdGKwvJsEB/Yt7xXO0Bd5yUtQoXi1BPUlVsssDCz799u/qdSbXCo75OKt7Y60h6us+aA3FOcX6u9hieogF5JCD9z+LA8yA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=I4uXBhNP6UpN59iH3MTvQppI0+1iQ2urPHw9pmL1xgI8hWOT+2G0k0BYFtumzhF91kNOsO5y/fuY+8LMyXUdfNNwZqeD/CEntKSUoVFjQr7y/LFS61LDYftBTh8SNkJNOJw2ppHxPwXQiTsfH3ZWUrrJcGNBEikG7pNozbJOMt+4gTli9a+mXJ5msvanyjD9yCL67kOr3eO/bbHjLDOx1ShaynTddJUafQF4mcmN5e4e9bPyyFBhxogqy65IxcgcZpeuHVwpUVGrKVkrqQABSGEOLKxVZhe6oKvJ5IuX5irLNVBsoz8xdFGbPeVV/IZGO5XmfFxRS/ABRLS3ot2rTQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Fri, 05 Dec 2025 13:53:25 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Apr 26, 2022 at 12:26:10PM +0200, Jan Beulich wrote:
> Just like for PV guests MMU_MACHPHYS_UPDATE implies marking of the
> respective page as dirty, additions to a HVM guest's P2M should do so.
> 
> For HVM the opposite is also true: Pages being removed from the P2M are
> no longer dirty at their prior GFN; there's no point in telling the tool
> stack to try and copy that page, when this will fail anyway (until
> perhaps a new page gets placed there). Introduce paging_mark_pfn_clean()
> (intentionally without a paging_mark_clean() counterpart) to handle
> this. Note that while there is an earlier call to set_gpfn_from_mfn() in
> guest_physmap_add_entry(), but there's little reason to mark the page
> clean there when later in the function it'll be marked dirty. This is
> even more so given that at this point it's only the M2P that gets
> updated, with the P2M still left unchanged.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> p2m_add_page()'s error handling looks bogus in this regard anyway: If an
> error occurs before an MFN actually is assciated with the new GFN, the
> M2P entry ought to be restored imo. But of course a guest is still hosed
> if the operation succeeds partially.
> 
> Note that I've not even checked mem-paging and mem-sharing code for
> whether they may need similar adjustment. At least the latters is, aiui,
> incompatible with log-dirty mode anyway.
> ---
> v3: Re-base.
> 
> --- 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()?

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.

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

Thanks, Roger.



 


Rackspace

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