All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Andryuk <jason.andryuk@amd.com>
To: "Roger Pau Monné" <roger@xenproject.org>,
	"Jan Beulich" <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	"Julien Grall" <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	<xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support
Date: Wed, 9 Sep 2026 16:07:32 -0400	[thread overview]
Message-ID: <22028c12-2400-4131-8e5e-b2dc7a65326f@amd.com> (raw)
In-Reply-To: <aqGJJTbVNID0Rq6w@macbook.local>

On 2026-09-09 12:28, Roger Pau Monné wrote:
> On Wed, Sep 09, 2026 at 04:46:01PM +0200, Jan Beulich wrote:
>> On 09.09.2026 16:05, Roger Pau Monne wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -1538,8 +1538,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn)
>>>           BUG();
>>>       }
>>>   
>>> -    /* If a page has no owner it will need no safety TLB flush. */
>>> -    pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL);
>>> +    /*
>>> +     * If a page has no owner and there's no PV domain support it will need no
>>> +     * safety TLB flush, there can be no stale TLB entries.
>>> +     */
>>> +    pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg);
>>>       if ( pg->u.free.need_tlbflush )
>>>           page_set_tlbflush_timestamp(pg);
>>
>> I'm okay with the code change now, but the comment is still concerning me.
>> All by itself there is no reason why stale TLB entries couldn't also exist
>> for HVM guests. It's just that (a) only the host TLBs are flushed by
>> filtered_flush_tlb_mask() and (b) flushes of guest TLBs occur when pages
>> are removed from their P2Ms (aiui; hopefully true also for Arm). IOW what
>> the comment says looks to be correct, just that it leaves too much to be
>> figured out by the reader. At the very least I'd suggest "..., there can
>> be no stale (host) TLB entries." Thoughts?
> 
> Hm, I find adding "(host)" to also be slightly confusing, as I would
> usually associate host TLB with Xen context TLB state.  Which is also
> made more confusing by how PV guests share the page-tables with Xen.
> 
> "If a page has no owner and there's no PV domain support it will need
> no safety TLB flush.  PV domains are the only domain types that can
> keep stale entries on the TLB, as they have (limited) control over the
> host MMU and when flushes are performed"
I find "will need no" a little awkward.  Maybe:

"If a page has no owner and there's no PV domain support it does not 
need a safety TLB flush."

or:

"If a page has no owner and there's no PV domain support, then a safety 
TLB flush is not needed."

Regards,
Jason


  reply	other threads:[~2026-09-09 20:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09 14:05 [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support Roger Pau Monne
2026-09-09 14:46 ` Jan Beulich
2026-09-09 16:28   ` Roger Pau Monné
2026-09-09 20:07     ` Jason Andryuk [this message]
2026-09-10  6:33       ` Jan Beulich

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=22028c12-2400-4131-8e5e-b2dc7a65326f@amd.com \
    --to=jason.andryuk@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger@xenproject.org \
    --cc=sstabellini@kernel.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.