Re: [PATCH v2 2/2] vfio/type1: Set IOMMU_MMIO in dma->prot for MMIO-backed addresses

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Nov 07, 2025 at 04:19:35PM +0000, Wei Wang wrote:
> On Friday, November 7, 2025 11:57 PM, Jason Gunthorpe wrote:
> On Fri, Nov 07, 2025 at 03:49:17PM +0000, Wei Wang wrote:
> >    > (are you aware of any real examples in use?)
> >    > VM_IO should indicate MMIO, yes, but we don't actually check that in
> >    > this type 1 path..
> 
> >    Is it because VFIO type1 didn’t need to check for MMIO before?
> >    (not sure how this impacts this patch adding the VM_IO check for MMIO
> >    :) )
> 
> > Okay, but it still doesn't mean it has to be decrypted..
> 
> I think "decrypted or not" is the job of the 1st patch. For now,
> MMIO cannot be encrypted, particularly not via sme_set(). If MMIO
> encryption is ever introduced in the future, a new flag (probably
> different from sme_me_mask) would need to be added.

The kernel is using "decrypted" as some weirdo code-word to mean the
memory is shared with the hypervisor. Only on AMD does it even have
anything to do with actual memory encryption.

However when I look at swiotlb and dma coherent mmap I see it calls
set_memory_decrypted(), uses pgprot_decrypted(), but still uses
__sme_set() when forming the iommu page table??

So why is that OK, but MMIO needs to avoid the sme_set() in the iommu
page table?

IOW I would like to hear from AMD some clear rules when sme_set needs
to be called and when it isn't.

Then we can decide if VM_IO is sufficient and so on.

Jason