From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Alexey Kardashevskiy <aik@amd.com>,
Xu Yilun <yilun.xu@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
linux-coco@lists.linux.dev, linux-pci@vger.kernel.org,
gregkh@linuxfoundation.org, lukas@wunner.de,
suzuki.poulose@arm.com, sameo@rivosinc.com, zhiw@nvidia.com
Subject: Re: [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver
Date: Wed, 28 May 2025 17:47:19 +0530 [thread overview]
Message-ID: <yq5a8qmh53qo.fsf@kernel.org> (raw)
In-Reply-To: <20250527144516.GO61950@nvidia.com>
Jason Gunthorpe <jgg@nvidia.com> writes:
> On Tue, May 27, 2025 at 07:56:09PM +0530, Aneesh Kumar K.V wrote:
>> Jason Gunthorpe <jgg@nvidia.com> writes:
>>
>> > On Tue, May 27, 2025 at 05:18:01PM +0530, Aneesh Kumar K.V wrote:
>> >> > yeah, I guess, there is a couple of places like this
>> >> >
>> >> > git grep pci_dev drivers/iommu/iommufd/
>> >> >
>> >> > drivers/iommu/iommufd/device.c: struct pci_dev *pdev = to_pci_dev(idev->dev);
>> >> > drivers/iommu/iommufd/eventq.c: struct pci_dev *pdev = to_pci_dev(dev);
>> >> >
>> >> > Although I do not see any compelling reason to have pci_dev in the TSM API, struct device should just work and not spill any PCI details to IOMMUFD but whatever... Thanks,
>> >>
>> >> Getting the kvm reference is tricky here.
>> >
>> > The KVM will come from the viommu object, passed in by userspace that
>> > is the plan at least.. If you are not presenting a viommu to the guest
>> > then I imagine we would still have some kind of NOP viommu object..
>>
>> I assume you are not suggesting using IOMMU_VIOMMU_ALLOC? That would
>> break the ABI, which we need to maintain.
>
> Yes I am, what ABI are you talking about? CC is all new.
>
>> Instead, my approach uses VFIO_DEVICE_BIND_IOMMUFD to associate the KVM
>> context. The vfio device file descriptor had already been linked to the
>> KVM instance via KVM_DEV_VFIO_FILE_ADD.
>>
>> Through VFIO_DEVICE_BIND_IOMMUFD, we inherit the necessary KVM details
>> and pass them along to iommufd_device, and subsequently to
>> iommufd_vdevice, using IOMMU_VDEVICE_ALLOC.
>
> It is not OK, we want this in the viommu not the device for a bunch of
> other reasons. I don't want two copies of the KVM running around
> inside iommfd..
>
Ok, I updated the changes as below.
5 files changed, 161 insertions(+), 2 deletions(-)
drivers/iommu/iommufd/iommufd_private.h | 3 +
drivers/iommu/iommufd/main.c | 5 ++
drivers/iommu/iommufd/viommu.c | 134 +++++++++++++++++++++++++++++++-
include/linux/iommufd.h | 5 +-
include/uapi/linux/iommufd.h | 16 ++++
modified drivers/iommu/iommufd/iommufd_private.h
@@ -606,6 +606,8 @@ int iommufd_viommu_alloc_ioctl(struct iommufd_ucmd *ucmd);
void iommufd_viommu_destroy(struct iommufd_object *obj);
int iommufd_vdevice_alloc_ioctl(struct iommufd_ucmd *ucmd);
void iommufd_vdevice_destroy(struct iommufd_object *obj);
+int iommufd_vdevice_tsm_bind_ioctl(struct iommufd_ucmd *ucmd);
+int iommufd_vdevice_tsm_unbind_ioctl(struct iommufd_ucmd *ucmd);
struct iommufd_vdevice {
struct iommufd_object obj;
@@ -613,6 +615,7 @@ struct iommufd_vdevice {
struct iommufd_viommu *viommu;
struct device *dev;
u64 id; /* per-vIOMMU virtual ID */
+ bool tsm_bound;
};
#ifdef CONFIG_IOMMUFD_TEST
modified drivers/iommu/iommufd/main.c
@@ -320,6 +320,7 @@ union ucmd_buffer {
struct iommu_veventq_alloc veventq;
struct iommu_vfio_ioas vfio_ioas;
struct iommu_viommu_alloc viommu;
+ struct iommu_vdevice_id vdev_id;
#ifdef CONFIG_IOMMUFD_TEST
struct iommu_test_cmd test;
#endif
@@ -379,6 +380,10 @@ static const struct iommufd_ioctl_op iommufd_ioctl_ops[] = {
__reserved),
IOCTL_OP(IOMMU_VIOMMU_ALLOC, iommufd_viommu_alloc_ioctl,
struct iommu_viommu_alloc, out_viommu_id),
+ IOCTL_OP(IOMMU_VDEVICE_TSM_BIND, iommufd_vdevice_tsm_bind_ioctl,
+ struct iommu_vdevice_id, vdevice_id),
+ IOCTL_OP(IOMMU_VDEVICE_TSM_UNBIND, iommufd_vdevice_tsm_unbind_ioctl,
+ struct iommu_vdevice_id, vdevice_id),
#ifdef CONFIG_IOMMUFD_TEST
IOCTL_OP(IOMMU_TEST_CMD, iommufd_test, struct iommu_test_cmd, last),
#endif
modified drivers/iommu/iommufd/viommu.c
@@ -2,6 +2,57 @@
/* Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES
*/
#include "iommufd_private.h"
+#include "linux/tsm.h"
+
+#if IS_ENABLED(CONFIG_KVM)
+#include <linux/kvm_host.h>
+
+static void viommu_get_kvm_safe(struct iommufd_viommu *viommu, struct kvm *kvm)
+{
+ void (*put_fn)(struct kvm *kvm);
+ bool (*get_fn)(struct kvm *kvm);
+ bool ret;
+
+ if (!kvm)
+ return;
+
+ put_fn = symbol_get(kvm_put_kvm);
+ if (WARN_ON(!put_fn))
+ return;
+
+ get_fn = symbol_get(kvm_get_kvm_safe);
+ if (WARN_ON(!get_fn)) {
+ symbol_put(kvm_put_kvm);
+ return;
+ }
+
+ ret = get_fn(kvm);
+ symbol_put(kvm_get_kvm_safe);
+ if (!ret) {
+ symbol_put(kvm_put_kvm);
+ return;
+ }
+
+ viommu->put_kvm = put_fn;
+ viommu->kvm = kvm;
+}
+
+static void viommu_put_kvm(struct iommufd_viommu *viommu)
+{
+ if (!viommu->kvm)
+ return;
+
+ if (WARN_ON(!viommu->put_kvm))
+ goto clear;
+
+ viommu->put_kvm(viommu->kvm);
+ viommu->put_kvm = NULL;
+ symbol_put(kvm_put_kvm);
+
+clear:
+ viommu->kvm = NULL;
+}
+#endif
void iommufd_viommu_destroy(struct iommufd_object *obj)
{
@@ -12,6 +63,8 @@ void iommufd_viommu_destroy(struct iommufd_object *obj)
viommu->ops->destroy(viommu);
refcount_dec(&viommu->hwpt->common.obj.users);
xa_destroy(&viommu->vdevs);
+
+ viommu_put_kvm(viommu);
}
int iommufd_viommu_alloc_ioctl(struct iommufd_ucmd *ucmd)
@@ -68,10 +121,32 @@ int iommufd_viommu_alloc_ioctl(struct iommufd_ucmd *ucmd)
*/
viommu->iommu_dev = __iommu_get_iommu_dev(idev->dev);
+ /* get the kvm details if specified. */
+ if (cmd->kvm_vm_fd) {
+ struct kvm *kvm;
+ struct fd f = fdget(cmd->kvm_vm_fd);
+
+ if (!fd_file(f)) {
+ rc = -EBADF;
+ goto out_abort;
+ }
+
+ if (!file_is_kvm(fd_file(f))) {
+ rc = -EBADF;
+ fdput(f);
+ goto out_abort;
+ }
+ kvm = fd_file(f)->private_data;
+ viommu_get_kvm_safe(viommu, kvm);
+ fdput(f);
+ }
+
cmd->out_viommu_id = viommu->obj.id;
rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
- if (rc)
+ if (rc) {
+ viommu_put_kvm(viommu);
goto out_abort;
+ }
iommufd_object_finalize(ucmd->ictx, &viommu->obj);
goto out_put_hwpt;
@@ -90,6 +165,9 @@ void iommufd_vdevice_destroy(struct iommufd_object *obj)
container_of(obj, struct iommufd_vdevice, obj);
struct iommufd_viommu *viommu = vdev->viommu;
+ if (vdev->tsm_bound)
+ tsm_unbind(vdev->dev);
+
/* xa_cmpxchg is okay to fail if alloc failed xa_cmpxchg previously */
xa_cmpxchg(&viommu->vdevs, vdev->id, vdev, NULL, GFP_KERNEL);
refcount_dec(&viommu->obj.users);
@@ -157,3 +235,57 @@ int iommufd_vdevice_alloc_ioctl(struct iommufd_ucmd *ucmd)
iommufd_put_object(ucmd->ictx, &viommu->obj);
return rc;
}
+
+int iommufd_vdevice_tsm_bind_ioctl(struct iommufd_ucmd *ucmd)
+{
+ struct iommu_vdevice_id *cmd = ucmd->cmd;
+ struct iommufd_vdevice *vdev;
+ int rc = 0;
+
+ vdev = container_of(iommufd_get_object(ucmd->ictx, cmd->vdevice_id,
+ IOMMUFD_OBJ_VDEVICE),
+ struct iommufd_vdevice, obj);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ rc = tsm_bind(vdev->dev, vdev->viommu->kvm, vdev->id);
+ if (rc) {
+ rc = -ENODEV;
+ goto out_put_vdev;
+ }
+
+ /* locking? */
+ vdev->tsm_bound = true;
+ rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
+
+out_put_vdev:
+ iommufd_put_object(ucmd->ictx, &vdev->obj);
+ return rc;
+}
+
+int iommufd_vdevice_tsm_unbind_ioctl(struct iommufd_ucmd *ucmd)
+{
+ struct iommu_vdevice_id *cmd = ucmd->cmd;
+ struct iommufd_vdevice *vdev;
+ int rc = 0;
+
+ vdev = container_of(iommufd_get_object(ucmd->ictx, cmd->vdevice_id,
+ IOMMUFD_OBJ_VDEVICE),
+ struct iommufd_vdevice, obj);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ rc = tsm_unbind(vdev->dev);
+ if (rc) {
+ rc = -ENODEV;
+ goto out_put_vdev;
+ }
+
+ /* locking ? */
+ vdev->tsm_bound = false;
+ rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
+
+out_put_vdev:
+ iommufd_put_object(ucmd->ictx, &vdev->obj);
+ return rc;
+}
modified include/linux/iommufd.h
@@ -51,8 +51,9 @@ struct iommufd_object {
unsigned int id;
};
+struct kvm;
struct iommufd_device *iommufd_device_bind(struct iommufd_ctx *ictx,
- struct device *dev, u32 *id);
+ struct device *dev, struct kvm *kvm, u32 *id);
void iommufd_device_unbind(struct iommufd_device *idev);
int iommufd_device_attach(struct iommufd_device *idev, ioasid_t pasid,
@@ -94,6 +95,8 @@ struct iommufd_viommu {
struct iommufd_ctx *ictx;
struct iommu_device *iommu_dev;
struct iommufd_hwpt_paging *hwpt;
+ struct kvm *kvm;
+ void (*put_kvm)(struct kvm *kvm);
const struct iommufd_viommu_ops *ops;
modified include/uapi/linux/iommufd.h
@@ -56,6 +56,8 @@ enum {
IOMMUFD_CMD_VDEVICE_ALLOC = 0x91,
IOMMUFD_CMD_IOAS_CHANGE_PROCESS = 0x92,
IOMMUFD_CMD_VEVENTQ_ALLOC = 0x93,
+ IOMMUFD_CMD_VDEVICE_TSM_BIND = 0x94,
+ IOMMUFD_CMD_VDEVICE_TSM_UNBIND = 0x95,
};
/**
@@ -985,6 +987,7 @@ struct iommu_viommu_alloc {
__u32 dev_id;
__u32 hwpt_id;
__u32 out_viommu_id;
+ __u32 kvm_vm_fd;
};
#define IOMMU_VIOMMU_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_VIOMMU_ALLOC)
@@ -1038,6 +1041,19 @@ enum iommu_veventq_flag {
IOMMU_VEVENTQ_FLAG_LOST_EVENTS = (1U << 0),
};
+/**
+ * struct iommu_vdevice_id - ioctl(IOMMU_VDEVICE_TSM_BIND/UNBIND)
+ * @size: sizeof(struct iommu_vdevice_id)
+ * @vdevice_id: Object handle for the vDevice. Returned from IOMMU_VDEVICE_ALLOC
+ */
+struct iommu_vdevice_id {
+ __u32 size;
+ __u32 vdevice_id;
+} __packed;
+#define IOMMU_VDEVICE_TSM_BIND _IO(IOMMUFD_TYPE, IOMMUFD_CMD_VDEVICE_TSM_BIND)
+#define IOMMU_VDEVICE_TSM_UNBIND _IO(IOMMUFD_TYPE, IOMMUFD_CMD_VDEVICE_TSM_UNBIND)
+
+
/**
* struct iommufd_vevent_header - Virtual Event Header for a vEVENTQ Status
* @flags: Combination of enum iommu_veventq_flag
>
>> >> + if (rc) {
>> >> + rc = -ENODEV;
>> >> + goto out_put_vdev;
>> >> + }
>> >> +
>> >> + /* locking? */
>> >> + vdev->tsm_bound = true;
>> >> + refcount_inc(&vdev->obj.users);
>> >
>> > This refcount isn't going to work, it will make an error close()
>> > crash..
>> >
>> > You need to auto-unbind on destruction I think.
>>
>> Can you elaborate on that? if vdevice is tsm_bound,
>> iommufd_vdevice_destroy() do call tsm_unbind in the changes I shared.
>
> You are driving it from the vfio side? Then you don't need the
> refcount at all here because the vfio facing APIs already take one.
I am using iommufd ioctl to bind/unbind. The goal was to call tsm_unbind
when we close the iommu file descriptor( So when a vdevice object is
destroyed).
-aneesh
next prev parent reply other threads:[~2025-05-28 12:17 UTC|newest]
Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 5:47 [PATCH v3 00/13] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2025-05-16 5:47 ` [PATCH v3 01/13] coco/tsm: Introduce a core device for TEE Security Managers Dan Williams
2025-06-02 13:18 ` Jason Gunthorpe
2025-06-04 0:42 ` Dan Williams
2025-06-04 1:15 ` Dan Williams
2025-06-04 12:15 ` Jason Gunthorpe
2025-06-04 12:14 ` Jason Gunthorpe
2025-06-06 3:33 ` Alexey Kardashevskiy
2025-06-06 2:09 ` Alexey Kardashevskiy
2025-05-16 5:47 ` [PATCH v3 02/13] PCI/IDE: Enumerate Selective Stream IDE capabilities Dan Williams
2025-06-17 12:16 ` Jonathan Cameron
2025-07-12 22:31 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 03/13] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2025-05-21 15:32 ` Aneesh Kumar K.V
2025-06-03 19:53 ` Dan Williams
2025-06-04 8:04 ` Aneesh Kumar K.V
2025-06-17 12:51 ` Jonathan Cameron
2025-07-12 22:07 ` dan.j.williams
2025-08-26 1:31 ` Alexey Kardashevskiy
2025-08-26 23:54 ` dan.j.williams
2025-08-27 4:44 ` Alexey Kardashevskiy
2025-08-28 19:27 ` dan.j.williams
2025-08-26 3:08 ` Alexey Kardashevskiy
2025-08-26 23:58 ` dan.j.williams
2025-08-27 5:06 ` Alexey Kardashevskiy
2025-08-26 10:22 ` Alexey Kardashevskiy
2025-08-27 0:15 ` dan.j.williams
2025-08-27 5:02 ` Alexey Kardashevskiy
2025-08-28 19:32 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 04/13] PCI: Enable host-bridge emulation for PCI_DOMAINS_GENERIC platforms Dan Williams
2025-05-16 5:47 ` [PATCH v3 05/13] PCI: vmd: Switch to pci_bus_find_emul_domain_nr() Dan Williams
2025-05-16 5:47 ` [PATCH v3 06/13] samples/devsec: Introduce a PCI device-security bus + endpoint sample Dan Williams
2025-06-17 13:30 ` Jonathan Cameron
2025-07-13 1:58 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 07/13] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2025-06-17 13:36 ` Jonathan Cameron
2025-05-16 5:47 ` [PATCH v3 08/13] PCI/IDE: Add IDE establishment helpers Dan Williams
2025-06-17 14:04 ` Jonathan Cameron
2025-07-14 18:25 ` dan.j.williams
2025-07-03 2:59 ` Alexey Kardashevskiy
2025-05-16 5:47 ` [PATCH v3 09/13] PCI/IDE: Report available IDE streams Dan Williams
2025-05-18 12:48 ` kernel test robot
2025-06-17 14:16 ` Jonathan Cameron
2025-07-14 20:16 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 10/13] PCI/TSM: Report active " Dan Williams
2025-06-17 14:21 ` Jonathan Cameron
2025-07-14 20:49 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 11/13] samples/devsec: Add sample IDE establishment Dan Williams
2025-06-17 14:26 ` Jonathan Cameron
2025-07-14 20:59 ` dan.j.williams
2025-05-16 5:47 ` [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver Dan Williams
2025-05-16 6:52 ` Xu Yilun
2025-05-20 7:17 ` Aneesh Kumar K.V
2025-05-21 9:35 ` Xu Yilun
2025-05-26 5:05 ` Aneesh Kumar K.V
2025-05-26 7:52 ` Alexey Kardashevskiy
2025-05-26 15:44 ` Aneesh Kumar K.V
2025-05-27 1:01 ` Alexey Kardashevskiy
2025-05-27 11:48 ` Aneesh Kumar K.V
2025-05-27 13:06 ` Jason Gunthorpe
2025-05-27 14:26 ` Aneesh Kumar K.V
2025-05-27 14:45 ` Jason Gunthorpe
2025-05-28 12:17 ` Aneesh Kumar K.V [this message]
2025-05-28 16:42 ` Jason Gunthorpe
2025-05-28 16:52 ` Jason Gunthorpe
2025-05-29 9:30 ` Xu Yilun
2025-05-29 13:43 ` Aneesh Kumar K.V
2025-05-29 14:09 ` Jason Gunthorpe
2025-05-30 3:00 ` Alexey Kardashevskiy
2025-05-30 13:21 ` Jason Gunthorpe
2025-05-29 13:49 ` Xu Yilun
2025-05-29 14:05 ` Jason Gunthorpe
2025-05-29 3:03 ` Alexey Kardashevskiy
2025-05-29 13:34 ` Aneesh Kumar K.V
2025-05-29 13:37 ` [RFC PATCH 1/3] coco: tsm: Add tsm_bind/unbind helpers Aneesh Kumar K.V (Arm)
2025-05-29 13:37 ` [RFC PATCH 2/3] iommufd/viommu: Add support to associate viommu with kvm instance Aneesh Kumar K.V (Arm)
2025-05-29 14:13 ` Jason Gunthorpe
2025-05-29 13:37 ` [RFC PATCH 3/3] iommufd/tsm: Add tsm_bind/unbind iommufd ioctls Aneesh Kumar K.V (Arm)
2025-05-29 14:32 ` Jason Gunthorpe
2025-05-30 8:33 ` Aneesh Kumar K.V
2025-05-30 18:18 ` Jason Gunthorpe
2025-05-31 16:25 ` Xu Yilun
2025-06-02 4:52 ` Alexey Kardashevskiy
2025-06-02 17:17 ` Xu Yilun
2025-06-04 1:47 ` Alexey Kardashevskiy
2025-06-04 5:02 ` Xu Yilun
2025-06-04 12:37 ` Jason Gunthorpe
2025-06-06 15:40 ` Xu Yilun
2025-06-06 16:34 ` Jason Gunthorpe
2025-06-09 4:47 ` Xu Yilun
2025-06-02 11:08 ` Aneesh Kumar K.V
2025-06-02 16:25 ` Xu Yilun
2025-06-02 16:48 ` Jason Gunthorpe
2025-06-03 4:05 ` Xu Yilun
2025-06-03 12:11 ` Jason Gunthorpe
2025-06-04 5:58 ` Xu Yilun
2025-06-04 12:36 ` Jason Gunthorpe
2025-06-05 3:05 ` Xu Yilun
2025-06-10 7:05 ` Alexey Kardashevskiy
2025-06-10 18:19 ` Jason Gunthorpe
2025-06-11 1:26 ` Alexey Kardashevskiy
2025-06-10 4:47 ` Alexey Kardashevskiy
2025-06-10 18:21 ` Jason Gunthorpe
2025-06-12 4:15 ` Xu Yilun
2025-06-03 5:00 ` Aneesh Kumar K.V
2025-06-03 10:50 ` Xu Yilun
2025-06-03 12:14 ` Jason Gunthorpe
2025-06-04 5:31 ` Xu Yilun
2025-06-04 12:31 ` Jason Gunthorpe
2025-06-05 3:25 ` Xu Yilun
2025-06-05 14:54 ` Jason Gunthorpe
2025-06-09 6:10 ` Xu Yilun
2025-06-09 16:42 ` Suzuki K Poulose
2025-06-09 18:07 ` Jason Gunthorpe
2025-06-10 7:31 ` Alexey Kardashevskiy
2025-06-12 5:44 ` Xu Yilun
2025-06-03 12:18 ` Jason Gunthorpe
2025-06-04 1:06 ` Dan Williams
2025-06-04 12:18 ` Jason Gunthorpe
2025-06-02 12:47 ` Jason Gunthorpe
2025-06-03 3:47 ` Xu Yilun
2025-06-03 12:08 ` Jason Gunthorpe
2025-06-04 6:39 ` Xu Yilun
2025-06-04 12:39 ` Jason Gunthorpe
2025-06-05 1:56 ` Xu Yilun
2025-07-15 10:29 ` Xu Yilun
2025-07-15 13:09 ` Jason Gunthorpe
2025-07-16 15:41 ` Xu Yilun
2025-07-16 16:31 ` Jason Gunthorpe
2025-07-17 8:28 ` Xu Yilun
2025-07-17 12:43 ` Jason Gunthorpe
2025-07-18 9:15 ` Xu Yilun
2025-07-18 12:26 ` Jason Gunthorpe
2025-07-20 2:37 ` Xu Yilun
2025-05-30 2:44 ` [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver Alexey Kardashevskiy
2025-05-27 10:25 ` Suzuki K Poulose
2025-06-03 22:47 ` Dan Williams
2025-06-04 1:35 ` Alexey Kardashevskiy
2025-06-04 1:52 ` Dan Williams
2025-06-04 1:54 ` Dan Williams
2025-06-05 10:56 ` Alexey Kardashevskiy
2025-06-07 1:56 ` Dan Williams
2025-06-11 4:40 ` Alexey Kardashevskiy
2025-06-13 3:06 ` Dan Williams
2025-06-03 22:40 ` Dan Williams
2025-05-19 10:20 ` Alexey Kardashevskiy
2025-05-20 20:12 ` Dan Williams
2025-05-21 9:28 ` Xu Yilun
2025-05-26 8:08 ` Alexey Kardashevskiy
2025-05-29 14:20 ` Xu Yilun
2025-05-30 2:54 ` Alexey Kardashevskiy
2025-05-31 15:26 ` Xu Yilun
2025-06-02 4:51 ` Alexey Kardashevskiy
2025-06-02 18:51 ` Xu Yilun
2025-06-03 19:12 ` Dan Williams
2025-07-07 7:17 ` Aneesh Kumar K.V
2025-05-20 5:20 ` Aneesh Kumar K.V
2025-05-20 21:12 ` Dan Williams
2025-05-16 5:47 ` [PATCH v3 13/13] PCI/TSM: Add Guest TSM Support Dan Williams
2025-05-19 10:20 ` Alexey Kardashevskiy
2025-05-20 21:11 ` Dan Williams
2025-05-22 4:07 ` Alexey Kardashevskiy
2025-06-03 22:26 ` Dan Williams
2025-06-03 22:33 ` Jason Gunthorpe
2025-06-10 8:31 ` Alexey Kardashevskiy
2025-07-11 23:04 ` dan.j.williams
2025-05-20 9:25 ` Aneesh Kumar K.V
2025-05-20 21:27 ` Dan Williams
2025-05-20 11:00 ` Aneesh Kumar K.V
2025-05-20 21:31 ` Dan Williams
2025-06-03 19:07 ` Dan Williams
2025-05-21 15:03 ` Xu Yilun
2025-06-03 19:20 ` Dan Williams
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=yq5a8qmh53qo.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=aik@amd.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sameo@rivosinc.com \
--cc=suzuki.poulose@arm.com \
--cc=yilun.xu@linux.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;
as well as URLs for NNTP newsgroup(s).