Re: [PATCH] arm64: swiotlb: Keep the default size for protected guests

On Mon, Aug 10, 2026 at 04:44:51PM +0100, Catalin Marinas wrote:

On Mon, Aug 10, 2026 at 03:14:47PM +0100, Will Deacon wrote:

quoted

On Mon, Aug 10, 2026 at 10:08:18AM -0300, Jason Gunthorpe wrote:

quoted

On Mon, Aug 10, 2026 at 12:46:51PM +0100, Will Deacon wrote:

quoted

On Mon, Aug 10, 2026 at 01:37:11PM +0200, Marek Szyprowski wrote:

quoted

On 10.08.2026 12:20, Will Deacon wrote:

quoted

On Mon, Aug 10, 2026 at 02:59:42PM +0530, Aneesh Kumar K.V wrote:

quoted

Marek Szyprowski [off-list ref] writes:

quoted

On 07.08.2026 20:20, Jason Gunthorpe wrote:

quoted

On Fri, Aug 07, 2026 at 06:13:49PM +0000, Mostafa Saleh wrote:

quoted

But the whole thing is best effort anyway, the kernel picks
IO_TLB_DEFAULT_SIZE which does not depend on the system topology or
how many devices or how much DMA they do.
SWIOTLB memory is wasted if unused so we should be careful around
that as it would be the other way around and users would have to
decrease it manually.

Yeah, it is why the arch code shouldn't really be sizing it directly,
it should be done in common code and, yes, we are probably going to
have to do something alot smarter to have the common code better
auto-tune this for the CC case..

What about the $subject patch? I assume that it is still needed to

restore the behavior that was altered by the "[PATCH v8 00/23]

dma-mapping: Track shared DMA state through direct, pool and swiotlb

paths?" patchset?

I would request that we pick this patch to fix the regression described
in https://lore.kernel.org/all/yq5azeyxyfol.fsf@kernel.org/ (local).

I really don't think we need it. CCA hardware isn't exactly widespread
and the KVM host side patches don't appear close to being merged.

Does this mean that the branch for-next/coco [1] won't go to v7.3-rc1?

Let's not make progress on guest support contingent on KVM CCA host
side patches please. I expect the CSPs will have VM instance types
available based on CCA within quarters, and Linux as a Guest should
work in those environments regardless of what KVM is doing. I don't
really expect full KVM support for years, frankly, the patchset is
massive. Even Intel and AMD don't have full KVM support yet.

To be clear: the only part I'm pushing back on is the realm-specific hack
to size the SWIOTLB area in arch/arm64/. Even with that hack applied, I
don't believe a one-size-fits-all value is going to work for everybody,
so it was really great to see that special-case removed in:

https://lore.kernel.org/all/20260717180442.110954-18-aneesh.kumar@kernel.org/ (local)

We had Mostafa's patch here:

https://lore.kernel.org/all/20260603110522.3331819-4-smostafa@google.com/ (local)

adding the same swiotlb buffer allocation for pKVM guests and realms.

Yes, and I think that's bad for pKVM guests which is why I'm happy to
see that part removed.

Aneesh's cleanup of SWIOTLB_FORCE inadvertently removed the 'else'
clause and limited_addressing is now always checked, meaning that we get
size limiting irrespective of whether we still need a default swiotlb.

Inadvertently, perhaps, but it's got Tested-bys from three different
companies on it and I think it's a good change. I don't think we should
be special-casing these environments based on some random collection of
virtio devices in a testing setup.

Normally I would consider this a regression on top of mainline and
Mostafa's patches rather than a cleanup. However, if the default size of
the bounce buffer was never sufficient for realms, as you said, we may
need something better here anyway, so not worth fixing.

I can see x86 in mem_encrypt_setup_arch() adjusting the bounce buffer to
6% of the guest memory. We could make up similar logic for arm64 or we
could just rely on CONFIG_SWIOTLB_DYNAMIC (default off currently for
arm64 I think).

As Jason said, this should be done outside the arch code.

Will