[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SI2PR01MB4393E3BBA776A1B9FC6400D4DCC3A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>
Date: Fri, 7 Nov 2025 16:19:35 +0000
From: Wei Wang <wei.w.wang@...mail.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: "alex@...zbot.org" <alex@...zbot.org>, "suravee.suthikulpanit@....com"
<suravee.suthikulpanit@....com>, "thomas.lendacky@....com"
<thomas.lendacky@....com>, "joro@...tes.org" <joro@...tes.org>,
"kevin.tian@...el.com" <kevin.tian@...el.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "iommu@...ts.linux.dev"
<iommu@...ts.linux.dev>
Subject: Re: [PATCH v2 2/2] vfio/type1: Set IOMMU_MMIO in dma->prot for
MMIO-backed addresses
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.
Powered by blists - more mailing lists