Re: [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver

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

On Mon, Jun 02, 2025 at 02:51:53PM +1000, Alexey Kardashevskiy wrote:
> 
> 
> On 1/6/25 01:26, Xu Yilun wrote:
> > On Fri, May 30, 2025 at 12:54:44PM +1000, Alexey Kardashevskiy wrote:
> > > 
> > > 
> > > On 30/5/25 00:20, Xu Yilun wrote:
> > > > > > > 
> > > > > > > > > + * struct pci_tsm_guest_req_info - parameter for pci_tsm_ops.guest_req()
> > > > > > > > > + * @type: identify the format of the following blobs
> > > > > > > > > + * @type_info: extra input/output info, e.g. firmware error code
> > > > > > > > 
> > > > > > > > Call it "fw_ret"?
> > > > > > > 
> > > > > > > Sure.
> > > > > > 
> > > > > > This field is intended for out-of-blob values, like fw_ret. But fw_ret
> > > > > > is specified in GHCB and is vendor specific. Other vendors may also
> > > > > > have different values of this kind.
> > > > > > 
> > > > > > So I intend to gather these out-of-blob values in type_info, like:
> > > > > > 
> > > > > > enum pci_tsm_guest_req_type {
> > > > > >      PCI_TSM_GUEST_REQ_TDXC,
> > > > > >      PCI_TSM_GUEST_REQ_SEV_SNP,
> > > > > > };
> > > > > 
> > > > > 
> > > > > The pci_tsm_ops hooks already know what they are - SEV or TDX.
> > > > 
> > > > I think this is for type safe check to some extend. The tsm driver hook
> > > > assumes the blobs are for its known format, but userspace may pass in
> > > > another format ...
> > > 
> > > The blobs are guest_request blobs, they enter the kernel via iommufd's viommu ioctl and viommu already has  iommu_viommu_type which is (in my tree):
> > > 
> > > enum iommu_viommu_type {
> > >          IOMMU_VIOMMU_TYPE_DEFAULT = 0,
> > >          IOMMU_VIOMMU_TYPE_ARM_SMMUV3 = 1,
> > >         IOMMU_VIOMMU_TYPE_AMD_TSM = 2,
> > >         IOMMU_VIOMMU_TYPE_AMD = 3,
> > >   };
> > 
> > That's a good point. So I think we don't have to use a 'type' field for
> > ioctl(IOMMUFD_VDEVICE_GUEST_REQUEST). But I didn't see these viommu_type
> > would be passed to TSM driver.So for this pci_tsm_guest_req kAPI, is it
> > still good we keep the 'type' for type safe check in TSM driver?
> This means that we somehow make it possible to create an Intel vdevice for the AMD TSM and now have to catch such situation  in runtime which seems wrong, we should not allow the mix in the first place. IOMMUFD is going to call the platform IOMMU code and that guy will just refuse creating a wrong viommu type.

That's good point, seems we should check if viommu type matches TSM ...
Need more investigations on it

> 
> 
> > > 
> > > > > 
> > > > > 
> > > > > > /* SEV SNP guest request type info */
> > > > > > struct pci_tsm_guest_req_sev_snp {
> > > > > > 	s32 fw_err;
> > > > > > };
> > > > > > 
> > > > > > Since IOMMUFD has the userspace entry, maybe these definitions should be
> > > > > > moved to include/uapi/linux/iommufd.h.
> > > > > > 
> > > > > > In pci-tsm.h, just define:
> > > > > > 
> > > > > > struct pci_tsm_guest_req_info {
> > > > > > 	u32 type;
> > > > > > 	void __user *type_info;
> > > > > > 	size_t type_info_len;
> > > > > > 	void __user *req;
> > > > > > 	size_t req_len;
> > > > > > 	void __user *resp;
> > > > > > 	size_t resp_len;
> > > > > > };
> > > > > > 
> > > > > > BTW: TDX Connect has no out-of-blob value, so should set type_info_len = 0
> > > > > 
> > > > > 
> > > > > No TDX Connect fw error handling on the host OS whatsoever, always return to the guest?
> > > > 
> > > > Always return to guest. The fw error info (not raw fw error code) is
> > > > embedded in response blob.
> > > > 
> > > > For QEMU/IOMMUFD, Guest Request doesn't care blob data, so don't have
> > > > to judge fw_error either. Alway return to the guest and let the guest
> > > > decide what to do.
> > > 
> > > So whatever is inside such requests, the host is not told about it ever? How does DOE bouncing work on Intel then if the fw cannot ask the host to do DOE? Thanks,
> > > 
> > 
> > No, I just say QEMU/IOMMUFD don't care about the execution, so no need
> > an explicit fw_err return to them. Platform TSM driver should definitely
> > know about fw_err and handle it (to do DOE or anything else) internally,
> > but don't have to EXPLICITLY propagate these error code to up layers (TSM
> > core/QEMU/IOMMUFD).
> 
> On AMD, the host has to provide certain handles along with the guest request/response buffers and the host can get it wrong so the host may want to know if the host did a wrong call. Say, we are killing a guest and by the same time making a guest request - will the Intel fw still say "that's ok, forward the response to the guest", even if it knows it is not possible?

For Intel, there is no 'guest_request' fw_call. Every GHCI call has
clear meaning to host (TSM driver) and host uses exact fw_calls to
complete each GHCI call.

Intel fw doesn't fill GHCI buffer, it just executes fw_call and
returns fw_err to host. Intel fw will not decide forwarding anything to
guest or not. It is the TSM driver's job to fill GHCI buffer according
to fw_call execution status.

That said, guest_request is just a QEMU selected set of GHCI commands.

For guest_request, a GHCI OK only means host has filled the response
buffer, host fills fw_err to the response buffer and guest should look
into the response buffer to see what really happened.

> Or SPDM session broke - the host OS won't be told until it specifically make a call other than guest request? Seems weird but okay. Thanks,
> 

The TDX TSM driver knows every detail of the execution of a fw_calls.

Thanks,
Yilun

> 
> > Thanks,
> > Yilun
> > 
> > > > > oookay, do not use it but the fw response is still a generic thing. Whatever is specific to AMD can be packed into req/resp and QEMU/guest will handle those.
> > > > 
> > > > But for out-of-blob data, it is the same effort as packing into type_info.
> > > > At least we could have a clear idea, which blob is SW defined, which blob
> > > > is GHCI/GHCB defined.
> > > > 
> > > > Thanks,
> > > > Yilun
> > > 
> > > -- 
> > > Alexey
> > > 
> 
> -- 
> Alexey
> 
>