Re: [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM

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

On Mon, Jun 02, 2025 at 10:37:27AM -0300, Jason Gunthorpe wrote:
> On Thu, May 29, 2025 at 01:34:43PM +0800, Xu Yilun wrote:
> 
> > This series has 3 sections:
> 
> I really think this is too big to try to progress, even in RFC
> form.

Sorry, I missed this message...

Yeah, I just try to give a overview of what components we need, what the
expect flow would be like for the first time. Also vendors need as much
components as possible to enable their own HW and verify this flow works.

We could split into small topics then.

>  
> > Patch 1 - 11 deal with the private MMIO mapping in KVM MMU via DMABUF.
> > Leverage Jason & Vivek's latest VFIO dmabuf series [3], see Patch 2 - 4.
> > The concern for get_pfn() kAPI [4] is not addressed so are marked as
> > HACK, will investigate later.
> 
> I would probably split this out entirely into its own topic. It
> doesn't seem directly related to TSM as KVM can use DMABUF for good
> reasons independently .

Yes, since I'm not work on improving this for now, I'll not include this
part next time. Will start independent thread if there is update.

> 
> > Patch 12 - 22 is about TSM Bind/Unbind/Guest request management in VFIO
> > & IOMMUFD. Picks some of Shameer's patch in [5], see Patch 12 & 14.
> 
> This is some reasonable topic on its own after Dan's series

OK, I'll just focus on this for next version.

>  
> > Patch 23 - 30 is a solution to meet the TDX specific sequence
> > enforcement on various device Unbind cases, including converting device
> > back to shared, hot unplug, TD destroy. Start with a tdx_tsm driver
> > prototype and finally implement the Unbind enforcement inside the
> > driver. To be honest it is still awkward to me, but I need help.
> 
> Then you have a series or two to implement TDX using the infrastructure.

Yeah, this should happen after "IOMMUFD for trusted".

Thanks,
Yilun

> 
> Jason