On 10/08/2026 2:08 pm, Jason Gunthorpe wrote:
On Mon, Aug 10, 2026 at 12:46:51PM +0100, Will Deacon wrote:
On Mon, Aug 10, 2026 at 01:37:11PM +0200, Marek Szyprowski wrote:
On 10.08.2026 12:20, Will Deacon wrote:
On Mon, Aug 10, 2026 at 02:59:42PM +0530, Aneesh Kumar K.V wrote:
Marek Szyprowski <[email protected]> writes:
On 07.08.2026 20:20, Jason Gunthorpe wrote:
On Fri, Aug 07, 2026 at 06:13:49PM +0000, Mostafa Saleh wrote:
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/[email protected]/.
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.
People already have CCA capable HW, are already testing this stuff and
the closer upstream can get to being workable as a guest without a
mountain of OOT patches the better.
I agree the thing is not ideal, but it was merged to ARM like this a
long time ago, this patch is just fixing a small oopsie (was it a
merge conflict?) to put it back. I don't the objection.
Yup, it seems pretty clearly like a straightforward bug in this series
(or maybe even just the merge resolution), where it should have just
removed the use of SWIOTLB_FORCE, but changing the if/else structure
inadvertently upset the whole flow in a way that it shouldn't have.
For a fix patch it might be clearer to restore the "(is_realm_world() ||
is_protected_kvm_guest())" condition exactly as before, then save any
further refactoring for the next round of new development. And if there
is a concern that skipping the resizing wastes memory for pKVM, then
surely that falls on e62decaf98e7 ("arm64/coco: Add pKVM as a CC
platform") which intentionally added that logic.
I do concur that there's not necessarily a mad panic to get this into
Marek's 7.3 pull, as folks trying to use linux-next or bleeding-edge
mainline for CCA work (or indeed anything) should know the risks, but it
should at least be one for the 7.3-rc fixes cycle. Aneesh, FYI generally
once things are queued, please just send follow-up fixes as their own
thing rather than replies, for maximum clarity.
Thanks,
Robin.
