From: Xu Yilun <yilun.xu@linux.intel.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: kvm@vger.kernel.org, sumit.semwal@linaro.org,
christian.koenig@amd.com, pbonzini@redhat.com, seanjc@google.com,
alex.williamson@redhat.com, jgg@nvidia.com,
dan.j.williams@intel.com, aik@amd.com,
linux-coco@lists.linux.dev, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
vivek.kasireddy@intel.com, yilun.xu@intel.com,
linux-kernel@vger.kernel.org, lukas@wunner.de,
yan.y.zhao@intel.com, daniel.vetter@ffwll.ch, leon@kernel.org,
baolu.lu@linux.intel.com, zhenzhong.duan@intel.com,
tao1.su@intel.com, linux-pci@vger.kernel.org, zhiw@nvidia.com,
simona.vetter@ffwll.ch, shameerali.kolothum.thodi@huawei.com,
iommu@lists.linux.dev, kevin.tian@intel.com
Subject: Re: [RFC PATCH 20/30] vfio/pci: Do TSM Unbind before zapping bars
Date: Mon, 2 Jun 2025 21:56:25 +0800 [thread overview]
Message-ID: <aD2ticKyMxxMXzZ+@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <yq5a34cilnxw.fsf@kernel.org>
On Mon, Jun 02, 2025 at 10:50:11AM +0530, Aneesh Kumar K.V wrote:
> Xu Yilun <yilun.xu@linux.intel.com> writes:
>
> > When device is TSM Bound, some of its MMIO regions are controlled by
> > secure firmware. E.g. TDX Connect would require these MMIO regions
> > mappeed in S-EPT and never unmapped until device Unbound. Zapping bars
> > irrespective of TSM Bound state may cause unexpected secure firmware
> > errors. It is always safe to do TSM Unbind first, transiting the device
> > to shared, then do whatever needed as before.
> >
> > Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> > ---
> > drivers/vfio/pci/vfio_pci_config.c | 4 +++
> > drivers/vfio/pci/vfio_pci_core.c | 41 +++++++++++++++++++-----------
> > drivers/vfio/pci/vfio_pci_priv.h | 3 +++
> > 3 files changed, 33 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> > index 7ac062bd5044..4ffe661c9e59 100644
> > --- a/drivers/vfio/pci/vfio_pci_config.c
> > +++ b/drivers/vfio/pci/vfio_pci_config.c
> > @@ -590,6 +590,7 @@ static int vfio_basic_config_write(struct vfio_pci_core_device *vdev, int pos,
> > new_mem = !!(new_cmd & PCI_COMMAND_MEMORY);
> >
> > if (!new_mem) {
> > + vfio_pci_tsm_unbind(vdev);
> > vfio_pci_zap_and_down_write_memory_lock(vdev);
> > vfio_pci_dma_buf_move(vdev, true);
> >
>
> Don't we need to re-bind the vdev with tsm_bind for the continued use of TDI?
I choose not to re-bind because host basically cannot recover
everything. The guest does 'bind', 'attest', 'accept' to make a trusted
device, but for this series VFIO is only aware of 'bind' and can only
recover 'bind', which doesn't make much sense. So I think just make
guest fully aware of TDISP rules, guest should expect writing MSE breaks
private state, and should do 'bind', 'attest', 'accept' again for
recovery if it wants to.
>
> > } else {
> > @@ -712,6 +713,7 @@ static void vfio_lock_and_set_power_state(struct vfio_pci_core_device *vdev,
> > pci_power_t state)
> > {
> > if (state >= PCI_D3hot) {
> > + vfio_pci_tsm_unbind(vdev);
> > vfio_pci_zap_and_down_write_memory_lock(vdev);
> > vfio_pci_dma_buf_move(vdev, true);
> > } else {
> > @@ -907,6 +909,7 @@ static int vfio_exp_config_write(struct vfio_pci_core_device *vdev, int pos,
> > &cap);
> >
> > if (!ret && (cap & PCI_EXP_DEVCAP_FLR)) {
> > + vfio_pci_tsm_unbind(vdev);
> > vfio_pci_zap_and_down_write_memory_lock(vdev);
> > vfio_pci_dma_buf_move(vdev, true);
> > pci_try_reset_function(vdev->pdev);
> > @@ -992,6 +995,7 @@ static int vfio_af_config_write(struct vfio_pci_core_device *vdev, int pos,
> > &cap);
> >
> > if (!ret && (cap & PCI_AF_CAP_FLR) && (cap & PCI_AF_CAP_TP)) {
> > + vfio_pci_tsm_unbind(vdev);
> > vfio_pci_zap_and_down_write_memory_lock(vdev);
> > vfio_pci_dma_buf_move(vdev, true);
> > pci_try_reset_function(vdev->pdev);
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> > index 92544e54c9c3..a8437fcecca1 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -286,6 +286,7 @@ static int vfio_pci_runtime_pm_entry(struct vfio_pci_core_device *vdev,
> > * The vdev power related flags are protected with 'memory_lock'
> > * semaphore.
> > */
> > + vfio_pci_tsm_unbind(vdev);
> > vfio_pci_zap_and_down_write_memory_lock(vdev);
> > vfio_pci_dma_buf_move(vdev, true);
> >
> > @@ -693,11 +694,7 @@ void vfio_pci_core_close_device(struct vfio_device *core_vdev)
> > eeh_dev_release(vdev->pdev);
> > #endif
> >
> > - if (vdev->is_tsm_bound) {
> > - vfio_iommufd_tsm_unbind(&vdev->vdev);
> > - pci_release_regions(vdev->pdev);
> > - vdev->is_tsm_bound = false;
> > - }
> > + __vfio_pci_tsm_unbind(vdev);
> >
> > vfio_pci_core_disable(vdev);
> >
> > @@ -1222,6 +1219,7 @@ static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev,
> > if (!vdev->reset_works)
> > return -EINVAL;
> >
> > + vfio_pci_tsm_unbind(vdev);
> > vfio_pci_zap_and_down_write_memory_lock(vdev);
> >
> > /*
> > @@ -1491,12 +1489,32 @@ static int vfio_pci_ioctl_tsm_bind(struct vfio_pci_core_device *vdev,
> > return ret;
> > }
> >
> > +void __vfio_pci_tsm_unbind(struct vfio_pci_core_device *vdev)
> > +{
> > + struct pci_dev *pdev = vdev->pdev;
> > +
> > + lockdep_assert_held(&vdev->vdev.dev_set->lock);
> > +
> > + if (!vdev->is_tsm_bound)
> > + return;
> > +
> > + vfio_iommufd_tsm_unbind(&vdev->vdev);
> > + pci_release_regions(pdev);
> > + vdev->is_tsm_bound = false;
> >
>
> Do we really need to check vdev->is_tsm_bound? The tsm_ops lock already
> ensures that concurrent TSM operations can't happen, and repeated calls
> to bind()/unbind() seem to be handled safely by pci_tsm_bind and pci_tsm_unbind.
It is mainly for pci_release_regions(). I remember there is a concern
about whether pci_request/release_region() should be in VFIO driver,
maybe lets solve that concern first in that thread.
>
> > +}
> > +
> > +void vfio_pci_tsm_unbind(struct vfio_pci_core_device *vdev)
> > +{
> > + mutex_lock(&vdev->vdev.dev_set->lock);
> > + __vfio_pci_tsm_unbind(vdev);
> > + mutex_unlock(&vdev->vdev.dev_set->lock);
> > +}
> >
>
> If is_tsm_bound is no longer needed, and pci_release_regions /
> request_region_exclusive are now handled within pci_tsm_unbind / bind,
> do we still need mutex_lock() to guard this path?
We may still need the dev_set->lock. The vfio_pci/iommufd_device_tsm_bind()
not only does pci_tsm_bind(), but also secure IOMMU setup which affects
all devices in the dev_set.
Maybe I worried too much, I doesn't know there exists a real secure device
set.
Thanks,
Yilun
next prev parent reply other threads:[~2025-06-02 14:03 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 5:34 [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 01/30] HACK: dma-buf: Introduce dma_buf_get_pfn_unlocked() kAPI Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 02/30] vfio: Export vfio device get and put registration helpers Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 03/30] vfio/pci: Share the core device pointer while invoking feature functions Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 04/30] vfio/pci: Allow MMIO regions to be exported through dma-buf Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 05/30] fixup! vfio/pci: fix dma-buf revoke typo on reset Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 06/30] HACK: vfio/pci: Support get_pfn() callback for dma-buf Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 07/30] KVM: Support vfio_dmabuf backed MMIO region Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 08/30] KVM: x86/mmu: Handle page fault for vfio_dmabuf backed MMIO Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 09/30] KVM: x86/mmu: Handle page fault for private MMIO Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 10/30] vfio/pci: Export vfio dma-buf specific info for importers Xu Yilun
2025-06-02 13:30 ` Jason Gunthorpe
2025-06-03 5:01 ` Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 11/30] KVM: vfio_dmabuf: Fetch VFIO specific dma-buf data for sanity check Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 12/30] iommufd/device: Associate a kvm pointer to iommufd_device Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 13/30] fixup! iommufd/selftest: Sync iommufd_device_bind() change to selftest Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 14/30] iommu/arm-smmu-v3-iommufd: Pass in kvm pointer to viommu_alloc Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 15/30] fixup: iommu/selftest: Sync .viommu_alloc() change to selftest Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 16/30] iommufd/viommu: track the kvm pointer & its refcount in viommu core Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 17/30] iommufd/device: Add TSM Bind/Unbind for TIO support Xu Yilun
2025-06-02 12:43 ` Aneesh Kumar K.V
2025-06-03 6:20 ` Xu Yilun
2025-06-03 12:21 ` Jason Gunthorpe
2025-06-04 8:40 ` Aneesh Kumar K.V
2025-06-04 13:24 ` Jason Gunthorpe
2025-06-06 7:59 ` Aneesh Kumar K.V
2025-05-29 5:35 ` [RFC PATCH 18/30] iommufd/viommu: Add trusted IOMMU configuration handlers for vdev Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 19/30] vfio/pci: Add TSM TDI bind/unbind IOCTLs for TEE-IO support Xu Yilun
2025-06-01 10:45 ` Aneesh Kumar K.V
2025-06-02 14:43 ` Xu Yilun
2025-06-04 13:37 ` Aneesh Kumar K.V
2025-06-05 9:41 ` Xu Yilun
2025-06-05 15:09 ` Jason Gunthorpe
2025-06-06 3:25 ` Xu Yilun
2025-06-05 16:09 ` Aneesh Kumar K.V
2025-06-16 8:16 ` Aneesh Kumar K.V
2025-06-18 4:54 ` Xu Yilun
2025-06-05 12:03 ` Aneesh Kumar K.V
2025-06-05 15:10 ` Jason Gunthorpe
2025-06-05 16:17 ` Aneesh Kumar K.V
2025-06-05 16:33 ` Jason Gunthorpe
2025-06-06 4:26 ` Xu Yilun
2025-06-06 9:32 ` Aneesh Kumar K.V
2025-06-06 12:09 ` Jason Gunthorpe
2025-05-29 5:35 ` [RFC PATCH 20/30] vfio/pci: Do TSM Unbind before zapping bars Xu Yilun
2025-06-02 5:20 ` Aneesh Kumar K.V
2025-06-02 13:56 ` Xu Yilun [this message]
2025-06-02 14:00 ` Aneesh Kumar K.V
2025-06-03 4:50 ` Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 21/30] iommufd/vdevice: Add TSM Guest request uAPI Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 22/30] fixup! PCI/TSM: Change the guest request type definition Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 23/30] coco/tdx_tsm: Introduce a "tdx" subsystem and "tsm" device Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 24/30] coco/tdx_tsm: TEE Security Manager driver for TDX Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 25/30] coco/tdx_tsm: Add connect()/disconnect() handlers prototype Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 26/30] coco/tdx_tsm: Add bind()/unbind()/guest_req() " Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 27/30] PCI/TSM: Add PCI driver callbacks to handle TSM requirements Xu Yilun
2025-06-02 13:06 ` Aneesh Kumar K.V
2025-06-03 5:52 ` Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 28/30] vfio/pci: Implement TSM handlers for MMIO Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 29/30] iommufd/vdevice: Implement TSM handlers for trusted DMA Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 30/30] coco/tdx_tsm: Manage TDX Module enforced operation sequences for Unbind Xu Yilun
2025-06-02 13:37 ` [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM Jason Gunthorpe
2025-06-20 4:21 ` Xu Yilun
2025-06-11 1:55 ` Alexey Kardashevskiy
2025-06-21 1:07 ` Alexey Kardashevskiy
2025-06-25 10:45 ` Xu Yilun
2025-07-11 23:08 ` dan.j.williams
2025-07-15 11:09 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aD2ticKyMxxMXzZ+@yilunxu-OptiPlex-7050 \
--to=yilun.xu@linux.intel.com \
--cc=aik@amd.com \
--cc=alex.williamson@redhat.com \
--cc=aneesh.kumar@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=simona.vetter@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--cc=tao1.su@intel.com \
--cc=vivek.kasireddy@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yilun.xu@intel.com \
--cc=zhenzhong.duan@intel.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox