[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALrP2iXyfU91-bg3u0mAL8zQrriuQMbdtJ1Hta9XeBRQ_vDEHQ@mail.gmail.com>
Date: Tue, 21 Jan 2025 17:27:45 +0800
From: Wencheng Yang <east.moutain.yang@...il.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Joerg Roedel <joro@...tes.org>, Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Alex Williamson <alex.williamson@...hat.com>, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v2] drviers/iommu/amd: support P2P access through IOMMU
when SME is enabled
On Mon, Jan 20, 2025 at 9:59 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Fri, Jan 17, 2025 at 03:14:18PM +0800, Wencheng Yang wrote:
> > When SME is enabled, memory encryption bit is set in IOMMU page table
> > pte entry, it works fine if the pfn of the pte entry is memory.
> > However, if the pfn is MMIO address, for example, map other device's mmio
> > space to its io page table, in such situation, setting memory encryption
> > bit in pte would cause P2P failure.
>
> This doesn't seem entirely right to me, the encrypted bit should flow
> in from the entity doing the map and be based on more detailed
> knowledge about what is happening.
>
> Not be guessed at inside the iommu.
>
> We have non-encrpyted CPU memory, and (someday) encrypted MMIO.
hi Jason
IOMMU shouldn't and can't guess the type of the mapping, e.g. memory
or device MMIO,
VFIO passes the info in a flag to IOMMU to setup IO page table entry.
There is another Qemu patch which will set the flag.
Qemu path: https://lists.nongnu.org/archive/html/qemu-devel/2025-01/msg02837.html
Thanks,
Wencheng
>
> Jason
Powered by blists - more mailing lists