public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Cc: "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"Xu, Terrence" <terrence.xu@intel.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com" 
	<shameerali.kolothum.thodi@huawei.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: Re: [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()
Date: Wed, 15 Mar 2023 02:03:09 -0700	[thread overview]
Message-ID: <ZBGJzefTm4p/ReIu@Asurada-Nvidia> (raw)
In-Reply-To: <BN9PR11MB52765D7977F987960072482E8CBF9@BN9PR11MB5276.namprd11.prod.outlook.com>

Hi,

On Wed, Mar 15, 2023 at 06:50:53AM +0000, Tian, Kevin wrote:

> > So, this preparatory series will add a pair of simple attach()
> > and detach() APIs. Then the cdev series will add the locking
> > and the ioas_unpin stuff as a rework of the detach() API.

> > I think they can be something mingled... the sample code that
> > I sent previously could take care of those conditions. But, I
> > am also thinking a bit that maybe attach() does not need the
> > locking? I can do a separate replace() function in this case.
> >
> 
> w/o locking then you need smp_store_release() and its pair.
> 
> anyway it's not in perf critical path. Keeping lock for attach
> is simpler and safe.

OK. Basically I followed what Jason suggested by having three
APIs and combined Kevin's inputs about the difference between
the attach/replace(). I also updated the replace changes, and
rebased all nesting (infrastructure, VT-d and SMMU):
https://github.com/nicolinc/iommufd/commits/wip/iommufd_nesting-03142023

The major three changes for those APIs:
[1] This adds iommufd_access_attach() in this series:
    "iommufd: Create access in vfio_iommufd_emulated_bind()"
    https://github.com/nicolinc/iommufd/commit/34fba7509429380f828fb23dcca5ceaeb40e22b5
[2] This adds iommufd_access_detach() in the cdev series:
    "iommufd/device: Add iommufd_access_detach() API"
    https://github.com/nicolinc/iommufd/commit/4110522146ca1fc0d5321c04a097e2c9d9e26af4
[3] This adds iommufd_access_replace() in the replace series:
    "iommufd: Add iommufd_access_replace() API"
    https://github.com/nicolinc/iommufd/commit/36507fa9f0f42cf1a5bebe7c9bc2bf319b7654a8

Please check if they look okay, so that Yi can integrate them
accordingly to the emulated/cdev series.

[*] This is the patch that I posted in the other mail addressing
    Kevin's comments on iommufd_ctx_get():
    "iommufd/device: Do iommufd_ctx_get() at the top of iommufd_access_create()"
    https://github.com/nicolinc/iommufd/commit/077b09bb83329dc046753f4ef672f5bf6386755c
    (I just saw Yi's reply concerning its necessity. Feel free
     to drop in that case.)

Thanks
Nicolin

P.S. Attaching the list of changes with their locations:
3791dedf98e8 cover-letter: Add IO page table replacement support
c8ebf51c3c9b vfio: Support IO page table replacement
c5710f23e8f6 iommufd/selftest: Add IOMMU_TEST_OP_ACCESS_REPLACE_IOAS coverage
[3] 36507fa9f0f4 iommufd: Add iommufd_access_replace() API
0263855d1e8b vfio: Do not allow !ops->dma_unmap in vfio_pin/unpin_pages()
e39ed55e77a0 cover-letter: Add vfio_device cdev for iommufd support
26fd7fccaef3 docs: vfio: Add vfio device cdev description
f10f3e3162bb vfio: Compile group optionally
9588ae4c4049 vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
3e57108eac64 vfio: Add VFIO_DEVICE_BIND_IOMMUFD
b925716dd226 vfio: Add cdev for vfio_device
db309463ab92 vfio-iommufd: Add detach_ioas support for emulated VFIO devices
[2] 4110522146ca iommufd/device: Add iommufd_access_detach() API
abca7e1e063a vfio-iommufd: Add detach_ioas support for physical VFIO devices
9d368f7247c7 vfio: Record devid in vfio_device_file
683af0a471e1 vfio-iommufd: Split the compat_ioas attach out from vfio_iommufd_bind()
32a2e7de1d53 vfio-iommufd: Split the no-iommu support out from vfio_iommufd_bind()
8a1c042379f5 vfio: Make vfio_device_first_open() to accept NULL iommufd for noiommu
fc6e0ed2aa44 vfio: Make vfio_device_open() single open for device cdev path
3f6821d507a4 vfio: Add cdev_device_open_cnt to vfio_group
896cde40a016 vfio: Block device access via device fd until device is opened
f422c4216a19 vfio: Pass struct vfio_device_file * to vfio_device_open/close()
b187f9980fed kvm/vfio: Accept vfio device file from userspace
721e2e60ff54 kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd
8993c4c75c20 vfio: Accept vfio device file in the KVM facing kAPI
a92c45ae0ce6 vfio: Remove vfio_file_is_group()
fb586f783934 vfio: Refine vfio file kAPIs for KVM
50694af6f3c0 vfio: Allocate per device file structure
df21c0737eef cover-letter: Make vfio-pci hot reset prepared for vfio device cdev
5c25c874d7e0 vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
7c30ce8b54db vfio: Accpet device file from vfio PCI hot reset path
e3209342db44 vfio: Refine vfio file kAPIs for vfio PCI hot reset
8354fd79944e vfio/pci: Rename the helpers and data in hot reset path to accept device fd
54387efb858c vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
cd93ffb62c51 vfio/pci: Only need to check opened devices in the dev_set for hot reset
2a6fd7231cbf vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()
480abea5961e cover-letter: vfio: Make emulated devices prepared for vfio device cdev
46b6d1ae1754 vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
6064b9f81817 Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers
c20852af7291 vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID
3405865b0b3f vfio-iommufd: No need to record iommufd_ctx in vfio_device
[*] 077b09bb8332 iommufd/device: Do iommufd_ctx_get() at the top of iommufd_access_create()
[1] 34fba7509429 iommufd: Create access in vfio_iommufd_emulated_bind()
a5d8ac47554f docs: kvm: vfio: Require call KVM_DEV_VFIO_GROUP_ADD before VFIO_GROUP_GET_DEVICE_FD

  reply	other threads:[~2023-03-15  9:03 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 13:13 [PATCH v1 0/5] vfio: Make emulated devices prepared for vfio device cdev Yi Liu
2023-03-08 13:13 ` [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind() Yi Liu
2023-03-10  2:08   ` Tian, Kevin
2023-03-14 18:50     ` Nicolin Chen
2023-03-15  6:16       ` Tian, Kevin
2023-03-15  6:21         ` Nicolin Chen
2023-03-15  6:52           ` Tian, Kevin
2023-03-15  8:52             ` Liu, Yi L
2023-03-16  0:17               ` Tian, Kevin
2023-03-16  0:28                 ` Nicolin Chen
2023-03-10 17:36   ` Jason Gunthorpe
2023-03-14  8:20     ` Nicolin Chen
2023-03-15  1:01       ` Nicolin Chen
2023-03-15  6:15         ` Tian, Kevin
2023-03-15  6:32           ` Nicolin Chen
2023-03-15  6:50             ` Tian, Kevin
2023-03-15  9:03               ` Nicolin Chen [this message]
2023-03-15 12:18                 ` Liu, Yi L
2023-03-16  0:32                   ` Nicolin Chen
2023-03-16  2:53                 ` Tian, Kevin
2023-03-16  3:25                   ` Nicolin Chen
2023-03-16  5:33                   ` Nicolin Chen
2023-03-16  5:38                     ` Tian, Kevin
2023-03-16  5:43                       ` Nicolin Chen
2023-03-16  5:49                         ` Tian, Kevin
2023-03-16  5:56                           ` Nicolin Chen
2023-03-16  6:01                           ` Liu, Yi L
2023-03-20 14:49                 ` Jason Gunthorpe
2023-03-20 15:11                   ` Yi Liu
2023-03-20 15:33                     ` Jason Gunthorpe
2023-03-08 13:13 ` [PATCH v1 2/5] vfio-iommufd: No need to record iommufd_ctx in vfio_device Yi Liu
2023-03-10 17:37   ` Jason Gunthorpe
2023-03-08 13:13 ` [PATCH v1 3/5] vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID Yi Liu
2023-03-10  2:08   ` Tian, Kevin
2023-03-10 17:37   ` Jason Gunthorpe
2023-03-08 13:13 ` [PATCH v1 4/5] Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers Yi Liu
2023-03-10  2:10   ` Tian, Kevin
2023-03-10 17:39   ` Jason Gunthorpe
2023-03-08 13:13 ` [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev() Yi Liu
2023-03-10  2:15   ` Tian, Kevin
2023-03-10 14:04     ` Jason Gunthorpe
2023-03-10 14:12       ` Liu, Yi L
2023-03-10 15:25         ` Jason Gunthorpe
2023-03-13  1:49       ` Tian, Kevin
2023-03-10 17:39   ` Jason Gunthorpe
2023-03-15 12:15     ` Liu, Yi L

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=ZBGJzefTm4p/ReIu@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=terrence.xu@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.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