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>
Subject: Re: [PATCH 2/3] x86/shadow: VRAM last_dirty tagging
Date: Mon, 27 Apr 2026 11:28:18 +0200	[thread overview]
Message-ID: <ae8sMiXAWjeXI3o1@macbook.local> (raw)
In-Reply-To: <8559db88-5f1d-4ced-980c-e71c4e229c7c@suse.com>

On Tue, Feb 03, 2026 at 05:49:55PM +0100, Jan Beulich wrote:
> ->last_dirty holding a valid value (one other than -1) is solely an
> indication of the bitmap being entirely clean. (The opposite isn't true,
> because of _sh_propagate() setting the field to a valid value without
> setting a bit in the bitmap.) As a consequence
> - setting the field to a valid value right after having allocated zero-
>   filled space is pointless,
> - copying the the all empty bitmap to the output array is pointless; with

Double 'the'?

>   the output array also having been allocated zero-filled, not even a
>   memset() is needed there,
> - after restoring bitmap contents when dealing with copy_to_guest() having
>   failed, the field needs setting to a valid value again.
> 
> Furthermore invoking NOW() in perhaps many loop iterations of the main
> loop is wasteful, too. Record whether any bit was set, and record a new
> ->last_dirty only once, after the loop. Then use the same NOW() value also
> for the subsequent check.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/mm/shadow/hvm.c
> +++ b/xen/arch/x86/mm/shadow/hvm.c
> @@ -1087,18 +1087,18 @@ int shadow_track_dirty_vram(struct domai
>          if ( (dirty_vram->dirty_bitmap = xzalloc_array(uint8_t, dirty_size)) == NULL )
>              goto out_sl1ma;
>  
> -        dirty_vram->last_dirty = NOW();
> +        dirty_vram->last_dirty = -1;
>  
>          /* Tell the caller that this time we could not track dirty bits. */
>          rc = -ENODATA;
>      }
> -    else if ( dirty_vram->last_dirty == -1 )
> -        /* still completely clean, just copy our empty bitmap */
> -        memcpy(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size);
> -    else
> +    /* Nothing to do when the bitmap is still completely clean. */
> +    else if ( dirty_vram->last_dirty != -1 )
>      {
>          mfn_t map_mfn = INVALID_MFN;
>          void *map_sl1p = NULL;
> +        bool any_dirty = false;
> +        s_time_t now;
>  
>          /* Iterate over VRAM to track dirty bits. */
>          for ( i = 0; i < nr_frames; i++ )
> @@ -1174,16 +1174,20 @@ int shadow_track_dirty_vram(struct domai
>              if ( dirty )
>              {
>                  dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
> -                dirty_vram->last_dirty = NOW();
> +                any_dirty = true;
>              }
>          }
>  
> +        now = NOW();
> +        if ( any_dirty )
> +            dirty_vram->last_dirty = now;

I'm a bit confused with the setting of ->last_dirty here ...

> +
>          if ( map_sl1p )
>              unmap_domain_page(map_sl1p);
>  
>          memcpy(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size);
>          memset(dirty_vram->dirty_bitmap, 0, dirty_size);

... as here the bitmap is zeroed, and hence ->last_dirty should be set
to -1?

> -        if ( dirty_vram->last_dirty + SECONDS(2) < NOW() )
> +        if ( dirty_vram->last_dirty + SECONDS(2) < now )
>          {
>              /*
>               * Was clean for more than two seconds, try to disable guest
> @@ -1216,6 +1220,7 @@ int shadow_track_dirty_vram(struct domai
>          paging_lock(d);
>          for ( i = 0; i < dirty_size; i++ )
>              dirty_vram->dirty_bitmap[i] |= dirty_bitmap[i];
> +        dirty_vram->last_dirty = NOW();

I think this is doesn't deserve a 'Fixes:' tag because the setting of
->last_dirty unconditionally to NOW() regardless of whether the bitmap
is zeroed?

Thanks, Roger.


  reply	other threads:[~2026-04-27  9:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 16:47 [PATCH 0/3] x86/shadow: tidy VRAM tracking a little Jan Beulich
2026-02-03 16:49 ` [PATCH 1/3] x86/shadow: unlock P2M slightly earlier in shadow_track_dirty_vram() Jan Beulich
2026-04-27  8:47   ` Roger Pau Monné
2026-05-04  8:21     ` Jan Beulich
2026-02-03 16:49 ` [PATCH 2/3] x86/shadow: VRAM last_dirty tagging Jan Beulich
2026-04-27  9:28   ` Roger Pau Monné [this message]
2026-05-04  8:39     ` Jan Beulich
2026-05-20 13:54       ` Roger Pau Monné
2026-05-20 14:25         ` Jan Beulich
2026-02-03 16:50 ` [PATCH 3/3] x86/shadow: reduce flush_tlb's scope in shadow_track_dirty_vram() Jan Beulich
2026-04-27  9:30   ` Roger Pau Monné

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=ae8sMiXAWjeXI3o1@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --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.