Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd

[Xu Yilun <yilun.xu@linux.intel.com>]

On Thu, Feb 26, 2026 at 09:09:02PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 26, 2026 at 04:28:53PM -0800, Sean Christopherson wrote:
> > > I'm confused though - I thought in-place conversion ment that
> > > private<->shared re-used the existing memory allocation? Why does it
> > > "remove" memory?
> > > 
> > > Or perhaps more broadly, where is the shared memory kept/accessed in
> > > these guest memfd systems?
> > 
> > Oh, the physical memory doesn't change, but the IOMMU might care that memory is
> > being converted from private<=>shared.  AMD IOMMU probably doesn't?  But unless
> > Intel IOMMU reuses S-EPT from the VM itself, the IOMMU page tables will need to

Intel secure IOMMU does reuse S-EPT, but that doesn't mean IOMMU mapping
stay still, at least IOTLB needs flush.

> > be updated.
> 
> Okay, so then it is probably OK for AMD and ARM to just let
> shared/private happen and whatever userspace does or doesn't do is not
> important. The IOPTE will point at guaranteed allocated memory and any
> faults caused by imporerly putting private in a shared slot will be
> contained.
> 
> I have no idea what happens to Intel if the shared IOMMU points to a
> private page? The machine catches fire and daemons spawn from a
> fissure?

Will cause host machine check and host restart, same as host CPU
accessing encrypted memory. Intel TDX has no lower level privilege
protection table so the wrong accessing will actually impact the
memory encryption engine.

> 
> Or maybe we are lucky and it generates a nice contained fault like the
> other two so we don't need to build something elaborate and special to
> make up for horrible hardware? Pretty please?
> 
> Jason