Alexey Kardashevskiy <[email protected]> writes:
> On 10/6/26 00:47, Jason Gunthorpe wrote:
>> On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote:
>>> On Thu, Jun 04, 2026 at 02:09:39PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>>> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
>>>> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
>>>> are handled consistently.
>>>>
>>>> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
>>>> shared/decrypted buffer handling. This series consolidates the
>>>> force_dma_unencrypted() checks in the top-level functions and ensures
>>>> that the remaining DMA interfaces use DMA attributes to make the correct
>>>> decisions.
>>>
>>> Please check Sashiko's reports, it has some good points:
>>>
>>> https://sashiko.dev/#/patchset/[email protected]
>>>
>>> I think the main one is the swiotlb_tbl_map_single() changes which break
>>> AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true
>>> but force_dma_unencrypted() is false. Normally you'd not end up on this
>>> path but you can have swiotlb=force.
>>
>> IMHO that's an AMD issue, not with the design of this series..
>>
>> The series is right, a device that is !force_dma_decrypted() must be
>> considerd to be a trusted device and we must never place any DMA
>> mappings for a trusted device into shared memory.
>
>
> swiotlb=force forces swiotlb, not decryption.
>
>> That AMD has done somethine insane:
>>
>> bool force_dma_unencrypted(struct device *dev)
>> {
>> /*
>> * For SEV, all DMA must be to unencrypted addresses.
>> */
>> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>> return true;
>>
>> /*
>> * For SME, all DMA must be to unencrypted addresses if the
>> * device does not support DMA to addresses that include the
>> * encryption mask.
>> */
>> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
>> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
>> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
>> dev->bus_dma_limit);
>>
>> if (dma_dev_mask <= dma_enc_mask)
>> return true;
>> }
>
>
> So when I try "mem_encrypt=on iommu=pt swiotlb=force" with this patchset, it
> fails to boot. But it boots with a hack like this:
>
> ===
> @@ -39,7 +41,7 @@ bool force_dma_unencrypted(struct device *dev)
> return true;
> }
>
> - return false;
> + return swiotlb_force_bounce;
> }
> ===
>
> Or we say "mem_encrypt=on iommu=pt swiotlb=force" combo is just weird and we
> won't be supporting which bit in this? Thanks,
>
Something like?
modified arch/x86/mm/mem_encrypt.c
@@ -34,6 +34,13 @@ bool force_dma_unencrypted(struct device *dev)
u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
dev->bus_dma_limit);
+ /*
+ * With memory encryption enabled, SWIOTLB is marked decrypted.
+ * If SWIOTLB bouncing is forced, treat the device as requiring
+ * decrypted DMA.
+ */
+ if (is_swiotlb_force_bounce(dev))
+ return true;
if (dma_dev_mask <= dma_enc_mask)
return true;
-aneesh
