arch/arm64/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Realm guests and protected KVM guests may require swiotlb for device DMA
even when all system RAM is addressable by the DMA zones.
Do not reduce the SWIOTLB buffer to the kmalloc-bouncing size for these
guests, as the reduced number of slots can be exhausted during CCA guest
operation.
Fixes: 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED")
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
arch/arm64/mm/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e308a7cabd12..24caaf10e755 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -339,7 +339,8 @@ void __init arch_mm_preinit(void)
{
unsigned int flags = SWIOTLB_VERBOSE;
- if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
+ if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
+ max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
/*
* If no bouncing needed for ZONE_DMA, reduce the swiotlb
* buffer for kmalloc() bouncing to 1MB per 1GB of RAM.
--
2.43.0On Fri, Aug 07, 2026 at 02:56:12PM +0530, Aneesh Kumar K.V (Arm) wrote:
> Realm guests and protected KVM guests may require swiotlb for device DMA
> even when all system RAM is addressable by the DMA zones.
>
> Do not reduce the SWIOTLB buffer to the kmalloc-bouncing size for these
> guests, as the reduced number of slots can be exhausted during CCA guest
> operation.
>
> Fixes: 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED")
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/mm/init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e308a7cabd12..24caaf10e755 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -339,7 +339,8 @@ void __init arch_mm_preinit(void)
> {
> unsigned int flags = SWIOTLB_VERBOSE;
>
> - if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> + if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
> + max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
Protected guests under pKVM rely on restricted DMA, so won't this just
waste memory for them?
Will
Will Deacon <will@kernel.org> writes:
> On Fri, Aug 07, 2026 at 02:56:12PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> Realm guests and protected KVM guests may require swiotlb for device DMA
>> even when all system RAM is addressable by the DMA zones.
>>
>> Do not reduce the SWIOTLB buffer to the kmalloc-bouncing size for these
>> guests, as the reduced number of slots can be exhausted during CCA guest
>> operation.
>>
>> Fixes: 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED")
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> arch/arm64/mm/init.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index e308a7cabd12..24caaf10e755 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -339,7 +339,8 @@ void __init arch_mm_preinit(void)
>> {
>> unsigned int flags = SWIOTLB_VERBOSE;
>>
>> - if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> + if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>> + max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>
> Protected guests under pKVM rely on restricted DMA, so won't this just
> waste memory for them?
>
commit 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED"),
which this patch fixes, has
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -339,9 +339,7 @@ void __init arch_mm_preinit(void)
{
unsigned int flags = SWIOTLB_VERBOSE;
- if (is_realm_world() || is_protected_kvm_guest()) {
- flags |= SWIOTLB_FORCE;
- } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
+ if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
/*
* If no bouncing needed for ZONE_DMA, reduce the swiotlb
* buffer for kmalloc() bouncing to 1MB per 1GB of RAM.
The is_protected_kvm_guest() part was added by the
commit e62decaf98e7 ("arm64/coco: Add pKVM as a CC platform")
@@ -337,7 +339,7 @@ void __init arch_mm_preinit(void)
{
unsigned int flags = SWIOTLB_VERBOSE;
- if (is_realm_world()) {
+ if (is_realm_world() || is_protected_kvm_guest()) {
flags |= SWIOTLB_FORCE;
} else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
/*
@@ -412,6 +414,17 @@ void dump_mem_limit(void)
}
}
I was under the impression that there is a possibility of using swiotlb
instead of restricted-dma-pool with pKVM. If that is not the case, then
we could change:
!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
to
!is_realm_world() &&
-aneesh
On Fri, Aug 07, 2026 at 06:33:14PM +0530, Aneesh Kumar K.V wrote:
> Will Deacon <will@kernel.org> writes:
>
> > On Fri, Aug 07, 2026 at 02:56:12PM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> Realm guests and protected KVM guests may require swiotlb for device DMA
> >> even when all system RAM is addressable by the DMA zones.
> >>
> >> Do not reduce the SWIOTLB buffer to the kmalloc-bouncing size for these
> >> guests, as the reduced number of slots can be exhausted during CCA guest
> >> operation.
> >>
> >> Fixes: 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED")
> >> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> >> ---
> >> arch/arm64/mm/init.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> index e308a7cabd12..24caaf10e755 100644
> >> --- a/arch/arm64/mm/init.c
> >> +++ b/arch/arm64/mm/init.c
> >> @@ -339,7 +339,8 @@ void __init arch_mm_preinit(void)
> >> {
> >> unsigned int flags = SWIOTLB_VERBOSE;
> >>
> >> - if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> >> + if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
> >> + max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> >
> > Protected guests under pKVM rely on restricted DMA, so won't this just
> > waste memory for them?
> >
>
> commit 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED"),
> which this patch fixes, has
>
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -339,9 +339,7 @@ void __init arch_mm_preinit(void)
> {
> unsigned int flags = SWIOTLB_VERBOSE;
>
> - if (is_realm_world() || is_protected_kvm_guest()) {
> - flags |= SWIOTLB_FORCE;
> - } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> + if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> /*
> * If no bouncing needed for ZONE_DMA, reduce the swiotlb
> * buffer for kmalloc() bouncing to 1MB per 1GB of RAM.
>
> The is_protected_kvm_guest() part was added by the
> commit e62decaf98e7 ("arm64/coco: Add pKVM as a CC platform")
>
> @@ -337,7 +339,7 @@ void __init arch_mm_preinit(void)
> {
> unsigned int flags = SWIOTLB_VERBOSE;
>
> - if (is_realm_world()) {
> + if (is_realm_world() || is_protected_kvm_guest()) {
> flags |= SWIOTLB_FORCE;
> } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
> /*
> @@ -412,6 +414,17 @@ void dump_mem_limit(void)
> }
> }
>
> I was under the impression that there is a possibility of using swiotlb
> instead of restricted-dma-pool with pKVM.
Yes, that patch enables swiotlb as a possibility for protected guests
but with your patch we avoid shrinking the swiotlb buffer even when
restricted dma pools are being used and that's a waste of memory.
> If that is not the case, then we could change:
>
> !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>
> to
>
> !is_realm_world() &&
Perhaps, or you could just pass the swiotlb= option if the defaults don't
work for you. Can you give more details about the slots exhaustion you're
seeing under CCA?
Will
Will Deacon <will@kernel.org> writes:
> On Fri, Aug 07, 2026 at 06:33:14PM +0530, Aneesh Kumar K.V wrote:
>> Will Deacon <will@kernel.org> writes:
>>
>> > On Fri, Aug 07, 2026 at 02:56:12PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> Realm guests and protected KVM guests may require swiotlb for device DMA
>> >> even when all system RAM is addressable by the DMA zones.
>> >>
>> >> Do not reduce the SWIOTLB buffer to the kmalloc-bouncing size for these
>> >> guests, as the reduced number of slots can be exhausted during CCA guest
>> >> operation.
>> >>
>> >> Fixes: 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED")
>> >> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> >> ---
>> >> arch/arm64/mm/init.c | 3 ++-
>> >> 1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> >> index e308a7cabd12..24caaf10e755 100644
>> >> --- a/arch/arm64/mm/init.c
>> >> +++ b/arch/arm64/mm/init.c
>> >> @@ -339,7 +339,8 @@ void __init arch_mm_preinit(void)
>> >> {
>> >> unsigned int flags = SWIOTLB_VERBOSE;
>> >>
>> >> - if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> >> + if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>> >> + max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> >
>> > Protected guests under pKVM rely on restricted DMA, so won't this just
>> > waste memory for them?
>> >
>>
>> commit 30c5e45ee2c5 ("dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED"),
>> which this patch fixes, has
>>
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -339,9 +339,7 @@ void __init arch_mm_preinit(void)
>> {
>> unsigned int flags = SWIOTLB_VERBOSE;
>>
>> - if (is_realm_world() || is_protected_kvm_guest()) {
>> - flags |= SWIOTLB_FORCE;
>> - } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> + if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> /*
>> * If no bouncing needed for ZONE_DMA, reduce the swiotlb
>> * buffer for kmalloc() bouncing to 1MB per 1GB of RAM.
>>
>> The is_protected_kvm_guest() part was added by the
>> commit e62decaf98e7 ("arm64/coco: Add pKVM as a CC platform")
>>
>> @@ -337,7 +339,7 @@ void __init arch_mm_preinit(void)
>> {
>> unsigned int flags = SWIOTLB_VERBOSE;
>>
>> - if (is_realm_world()) {
>> + if (is_realm_world() || is_protected_kvm_guest()) {
>> flags |= SWIOTLB_FORCE;
>> } else if (max_pfn <= PFN_DOWN(arm64_dma_phys_limit)) {
>> /*
>> @@ -412,6 +414,17 @@ void dump_mem_limit(void)
>> }
>> }
>>
>> I was under the impression that there is a possibility of using swiotlb
>> instead of restricted-dma-pool with pKVM.
>
> Yes, that patch enables swiotlb as a possibility for protected guests
> but with your patch we avoid shrinking the swiotlb buffer even when
> restricted dma pools are being used and that's a waste of memory.
>
The patch restores the behavior to what it was before that commit. That
is, for both CCA and pKVM, we don't do the max_pfn check, and hence the
swiotlb is never resized.
>
>> If that is not the case, then we could change:
>>
>> !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>>
>> to
>>
>> !is_realm_world() &&
>
> Perhaps, or you could just pass the swiotlb= option if the defaults don't
> work for you. Can you give more details about the slots exhaustion you're
> seeing under CCA?
That is definitely possible. However, on arm64, the current code further
reduces the default swiotlb size when max_pfn < arm64_dma_phys_limit.
That reduction is only correct when swiotlb is being used as a bounce
buffer because of arm64_dma_phys_limit.
With CCA, that is not the case. We use swiotlb to bounce DMA for
untrusted devices. Therefore, reducing the default swiotlb size based on
max_pfn is not correct for CCA configurations.
This change in behavior is also a regression for CCA. CCA configurations
that booted successfully before now gives the error below.
[ 39.848004] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 256 (slots), used 159 (slots)
[ 40.002654] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 256 (slots), used 159 (slots)
[ 40.165933] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 256 (slots), used 159 (slots)
[ 40.325465] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 512 (slots), used 415 (slots)
[ 40.485932] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 204800 bytes), total 768 (slots), used 671 (slots)
[ 42.485337] EXT4-fs (vda): re-mounted 6870157e-2795-475e-aad6-3a05725fb7cf.
[ 43.799800] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1280 (slots), used 1153 (slots)
[ 44.016682] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1280 (slots), used 1153 (slots)
[ 44.226566] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1536 (slots), used 1409 (slots)
[ 44.437194] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 262144 bytes), total 1792 (slots), used 1665 (slots)
-aneesh
On Fri, Aug 07, 2026 at 02:18:31PM +0100, Will Deacon wrote: > > I was under the impression that there is a possibility of using swiotlb > > instead of restricted-dma-pool with pKVM. > > Yes, that patch enables swiotlb as a possibility for protected guests > but with your patch we avoid shrinking the swiotlb buffer even when > restricted dma pools are being used and that's a waste of memory. I also thought we switched pkvm to use CC-like swiotlb as part of the alignment in this rework? Mostafa ? > > If that is not the case, then we could change: > > > > !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) && > > > > to > > > > !is_realm_world() && > > Perhaps, or you could just pass the swiotlb= option if the defaults don't > work for you. Can you give more details about the slots exhaustion you're > seeing under CCA? We see badness with swiotlb too, it basically doesn't work out of the box if you have to use it 100% for real devices. It easily runs out of memory. Auto tuning to higher levels makes sense to me, but I'd rather the core code handled adjusting its size to the estimated need, not arch code. Jason
Jason Gunthorpe <jgg@ziepe.ca> writes: > On Fri, Aug 07, 2026 at 02:18:31PM +0100, Will Deacon wrote: > >> > I was under the impression that there is a possibility of using swiotlb >> > instead of restricted-dma-pool with pKVM. >> >> Yes, that patch enables swiotlb as a possibility for protected guests >> but with your patch we avoid shrinking the swiotlb buffer even when >> restricted dma pools are being used and that's a waste of memory. > > I also thought we switched pkvm to use CC-like swiotlb as part of the > alignment in this rework? Mostafa ? > >> > If that is not the case, then we could change: >> > >> > !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) && >> > >> > to >> > >> > !is_realm_world() && >> >> Perhaps, or you could just pass the swiotlb= option if the defaults don't >> work for you. Can you give more details about the slots exhaustion you're >> seeing under CCA? > > We see badness with swiotlb too, it basically doesn't work out of the > box if you have to use it 100% for real devices. It easily runs out > of memory. > > Auto tuning to higher levels makes sense to me, but I'd rather the > core code handled adjusting its size to the estimated need, not arch > code. Agreed -aneesh
On Fri, Aug 07, 2026 at 10:58:10AM -0300, Jason Gunthorpe wrote: > On Fri, Aug 07, 2026 at 02:18:31PM +0100, Will Deacon wrote: > > > > I was under the impression that there is a possibility of using swiotlb > > > instead of restricted-dma-pool with pKVM. > > > > Yes, that patch enables swiotlb as a possibility for protected guests > > but with your patch we avoid shrinking the swiotlb buffer even when > > restricted dma pools are being used and that's a waste of memory. > > I also thought we switched pkvm to use CC-like swiotlb as part of the > alignment in this rework? Mostafa ? Yes, now protected VMs can use the SWIOTLB for bouncing. However for Android (and kvmtool), use restricted DMA. so SWIOTLB is not used. However, I do not think we should over engineer this in the code, swiotlb can be set from the cmdline and now through Kconfig also. Thanks, Mostafa > > > > If that is not the case, then we could change: > > > > > > !cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) && > > > > > > to > > > > > > !is_realm_world() && > > > > Perhaps, or you could just pass the swiotlb= option if the defaults don't > > work for you. Can you give more details about the slots exhaustion you're > > seeing under CCA? > > We see badness with swiotlb too, it basically doesn't work out of the > box if you have to use it 100% for real devices. It easily runs out > of memory. > > Auto tuning to higher levels makes sense to me, but I'd rather the > core code handled adjusting its size to the estimated need, not arch > code. > > Jason
On Fri, Aug 07, 2026 at 03:34:47PM +0000, Mostafa Saleh wrote: > On Fri, Aug 07, 2026 at 10:58:10AM -0300, Jason Gunthorpe wrote: > > On Fri, Aug 07, 2026 at 02:18:31PM +0100, Will Deacon wrote: > > > > > > I was under the impression that there is a possibility of using swiotlb > > > > instead of restricted-dma-pool with pKVM. > > > > > > Yes, that patch enables swiotlb as a possibility for protected guests > > > but with your patch we avoid shrinking the swiotlb buffer even when > > > restricted dma pools are being used and that's a waste of memory. > > > > I also thought we switched pkvm to use CC-like swiotlb as part of the > > alignment in this rework? Mostafa ? > > Yes, now protected VMs can use the SWIOTLB for bouncing. However for > Android (and kvmtool), use restricted DMA. so SWIOTLB is not used. Oh? Why? > However, I do not think we should over engineer this in the code, > swiotlb can be set from the cmdline and now through Kconfig also. That's fine for android, but real users buying a cloud VM and sticking a distro on it shouldn't be expected to have to mess with cmdline just go get a halfway working system Jason
On Fri, Aug 07, 2026 at 01:47:34PM -0300, Jason Gunthorpe wrote: > On Fri, Aug 07, 2026 at 03:34:47PM +0000, Mostafa Saleh wrote: > > On Fri, Aug 07, 2026 at 10:58:10AM -0300, Jason Gunthorpe wrote: > > > On Fri, Aug 07, 2026 at 02:18:31PM +0100, Will Deacon wrote: > > > > > > > > I was under the impression that there is a possibility of using swiotlb > > > > > instead of restricted-dma-pool with pKVM. > > > > > > > > Yes, that patch enables swiotlb as a possibility for protected guests > > > > but with your patch we avoid shrinking the swiotlb buffer even when > > > > restricted dma pools are being used and that's a waste of memory. > > > > > > I also thought we switched pkvm to use CC-like swiotlb as part of the > > > alignment in this rework? Mostafa ? > > > > Yes, now protected VMs can use the SWIOTLB for bouncing. However for > > Android (and kvmtool), use restricted DMA. so SWIOTLB is not used. > > Oh? Why? > The patches are not in Linux yet, when it eventually lands in Android it should be possible, I did some initial assessment and did not see any regressions. > > However, I do not think we should over engineer this in the code, > > swiotlb can be set from the cmdline and now through Kconfig also. > > That's fine for android, but real users buying a cloud VM and sticking > a distro on it shouldn't be expected to have to mess with cmdline just > go get a halfway working system 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. Thanks, Mostafa > > Jason
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.. Jason
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? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Marek Szyprowski <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. We can then work separately on improving the default swiotlb pool size in generic code based on other metrics. I consider this patch independent of that work. Even with such an improvement, this patch would still be applicable: a condition that resizes the swiotlb pool based on arm64_dma_phys_limit should not apply when guest memory encryption is in use, because the purpose of the swiotlb pool is different in that configuration. -aneesh
On Mon, Aug 10, 2026 at 02:59:42PM +0530, Aneesh Kumar K.V wrote: > Marek Szyprowski <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. 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. We have time to fix this properly, rather than papering over it in the arch code. Please consider this a NAK from the arm64 side on this patch. Will
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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. > 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? I've used it as a base for the mentioned DMA-mapping patchset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/coco > We have time to fix this properly, rather than papering over it in the > arch code. > > Please consider this a NAK from the arm64 side on this patch. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. > > 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? Argh, no, I'm definitely planning to send that! I'm just saying that this specific fixup patch (which is a PATCH sent in reply to another patch in the middle of a series...): https://lore.kernel.org/all/20260807092612.2202005-1-aneesh.kumar@kernel.org/ isn't something we should take for the upcoming merge window. There are better, alternative ways to tackle the issue (as discussed in the thread) and it's really not as urgent as Aneesh is trying to make it sound. Will
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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. > > > 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. Jason
Jason Gunthorpe <jgg@ziepe.ca> writes: > 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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. >> > > 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. > It was not a merge conflict issue. The change was introduced by an incorrect rebase I did when updating the patch series on top of the pKVM changes. -aneesh
On Mon, Aug 10, 2026 at 10:08:18AM -0300, 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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. > > > > 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/ but now, because it regresses some test configuration, the proposal was to penalise protected VMs too (bearing in mind that the patch above hasn't yet landed upstream): https://lore.kernel.org/all/20260807092612.2202005-1-aneesh.kumar@kernel.org/ with the alternative being to reintroduce the original hack that we just removed! https://lore.kernel.org/all/yq5acxvu2ict.fsf@kernel.org/ I'm saying: merge the patches as they are, without reintroducing this horrible bodge in the architecture code to drive a heuristic that most people seem to agree should be handled more robustly elsewhere. > 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. This specific part is about a single line of code, to control something which is already configurable in Kconfig and on the cmdline. It's not a mountain of out-of-tree patches. > 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. My main objection is that I have very little confidence in people trying to fix this properly if we take the realm-specific bodge in the arch code. With all the CCA patches floating about already, why would they? Will
On Mon, Aug 10, 2026 at 03:14:47PM +0100, Will Deacon wrote: > On Mon, Aug 10, 2026 at 10:08:18AM -0300, 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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. > > > > > 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/ We had Mostafa's patch here: https://lore.kernel.org/all/20260603110522.3331819-4-smostafa@google.com/ adding the same swiotlb buffer allocation for pKVM guests and realms. 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. 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). -- Catalin
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: > > On Mon, Aug 10, 2026 at 10:08:18AM -0300, 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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/. > > > > > > 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/ > > We had Mostafa's patch here: > > https://lore.kernel.org/all/20260603110522.3331819-4-smostafa@google.com/ > > 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
On Mon, Aug 10, 2026 at 04:58:42PM +0100, Will Deacon wrote: > On Mon, Aug 10, 2026 at 04:44:51PM +0100, Catalin Marinas wrote: > > 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. I agree, better in the core code. I'd prefer to go for some dynamic resizing than random percentage of guest memory like x86 (but, in the absence of dynamic swiotlb, we could pick some default). I noticed we still have a small change in behaviour regarding dynamic swiotlb. The increment for new allocations is based on default_nslabs which is reduced with the new patches. It gets even weirder if one sets the same IO_TLB_DEFAULT_SIZE on the kernel command line, it will be overridden by swiotlb_adjust_size() anyway. I think this core code needs a bit more tidying up. -- Catalin
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 <m.szyprowski@samsung.com> 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/yq5azeyxyfol.fsf@kernel.org/.
>>>> 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.
© 2016 - 2026 Red Hat, Inc.