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>
Subject: Re: [PATCH v2 4/6] VT-d: restrict iommu_flush_all() to cache writeback
Date: Wed, 14 May 2025 13:40:10 +0200 [thread overview]
Message-ID: <aCSBGhD2DwS3K3C-@macbook.lan> (raw)
In-Reply-To: <bf99949c-0e09-13a5-3ad9-a6c26377bdbf@suse.com>
On Wed, May 03, 2023 at 11:46:11AM +0200, Jan Beulich wrote:
> We don't need to invalidate caches here; all we're after is that earlier
> writes have made it to main memory (and aiui even that just in case).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This, aiui, being an analogue to uses of iommu_sync_cache() (just not
> range restricted), I wonder whether it shouldn't be conditional upon
> iommu_non_coherent. Then again I'm vaguely under the impression that
> we had been here before, possibly even as far as questioning the need
> for this call altogether.
I think yes, it would better be only done for iommu_non_coherent. Yet
in that case I wonder why we need this wide flush. In principle all
accesses should already have their own write-back calls if the IOMMU
is non-coherent?
There's maybe the call from vtd_crash_shutdown() which I guess could
trigger in the middle of some interaction with the IOMMU, but at that
point do we really care to flush anyway if Xen is going to crash?
Otherwise it seems fine to switch to write-back.
Thanks, Roger.
next prev parent reply other threads:[~2025-05-14 11:40 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é
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é [this message]
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=aCSBGhD2DwS3K3C-@macbook.lan \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.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.