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>,
	Kevin Tian <kevin.tian@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache writeback
Date: Tue, 13 May 2025 15:41:37 +0200	[thread overview]
Message-ID: <aCNMEadsYoIKLbSp@macbook.lan> (raw)
In-Reply-To: <d55070c0-04c5-70a4-f9f3-3227d42578e6@suse.com>

On Wed, May 03, 2023 at 11:45:22AM +0200, Jan Beulich wrote:
> We allow its use for writeback purposes only anyway, so let's also carry
> these out that way on capable hardware.

"for writeback purposes only" > is such the case because we cannot
guarantee the guest in which state the cache will be when resuming
from a wbinvd operation, and hence won't be "clean"?

It's my understanding that the same is possible on native, as the CPU
might speculatively pull lines into the cache.  So there's no reason
for an OS to use wbinvd if wbnoinvd is available?

Thanks, Roger.


  parent reply	other threads:[~2025-05-13 13:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03  9:43 [PATCH v2 0/6] x86: reduce cache flushing overhead Jan Beulich
2023-05-03  9:44 ` [PATCH v2 1/6] x86: support cache-writeback in flush_area_local() et al Jan Beulich
2025-05-13 13:01   ` Roger Pau Monné
2023-05-03  9:45 ` [PATCH v2 2/6] x86/HVM: restrict guest-induced WBINVD to cache writeback Jan Beulich
2025-05-13 13:12   ` Andrew Cooper
2025-05-13 13:24     ` Jan Beulich
2025-05-13 13:41   ` Roger Pau Monné [this message]
2025-05-13 13:54     ` Jan Beulich
2025-05-14 11:30       ` Roger Pau Monné
2025-05-14 12:46         ` Jan Beulich
2025-05-14 14:42           ` Roger Pau Monné
2025-05-14 14:53             ` Jan Beulich
2023-05-03  9:45 ` [PATCH v2 3/6] x86/PV: restrict guest-induced WBINVD (or alike) " Jan Beulich
2023-05-03  9:46 ` [PATCH v2 4/6] VT-d: restrict iommu_flush_all() " Jan Beulich
2025-05-14 11:40   ` Roger Pau Monné
2025-05-14 12:49     ` Jan Beulich
2025-05-14 14:44   ` Roger Pau Monné
2025-05-14 14:57     ` Jan Beulich
2023-05-03  9:46 ` [PATCH v2 5/6] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT Jan Beulich
2025-05-14 11:44   ` Roger Pau Monné
2025-05-14 12:52     ` Jan Beulich
2025-05-14 14:45       ` Roger Pau Monné
2025-05-15  6:46         ` Jan Beulich
2023-05-03  9:47 ` [PATCH v2 6/6] x86/HVM: limit cache writeback overhead Jan Beulich
2025-05-14 13:00   ` Roger Pau Monné
2025-05-14 13:20     ` Jan Beulich
2025-05-14 15:12       ` Roger Pau Monné
2025-05-15  6:47         ` Jan Beulich
2025-05-15  8:09           ` 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=aCNMEadsYoIKLbSp@macbook.lan \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.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.