From: "Liu, Yi L" <yi.l.liu@intel.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "hch@lst.de" <hch@lst.de>, "jasowang@redhat.com" <jasowang@redhat.com>, "joro@8bytes.org" <joro@8bytes.org>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "Tian, Kevin" <kevin.tian@intel.com>, "parav@mellanox.com" <parav@mellanox.com>, "lkml@metux.net" <lkml@metux.net>, "pbonzini@redhat.com" <pbonzini@redhat.com>, "lushenming@huawei.com" <lushenming@huawei.com>, "eric.auger@redhat.com" <eric.auger@redhat.com>, "corbet@lwn.net" <corbet@lwn.net>, "Raj, Ashok" <ashok.raj@intel.com>, "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>, "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>, "Jiang, Dave" <dave.jiang@intel.com>, "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>, "kwankhede@nvidia.com" <kwankhede@nvidia.com>, "robin.murphy@arm.com" <robin.murphy@arm.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "dwmw2@infradead.org" <dwmw2@infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>, "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>, "nicolinc@nvidia.com" <nicolinc@nvidia.com> Subject: RE: [RFC 02/20] vfio: Add device class for /dev/vfio/devices Date: Fri, 29 Oct 2021 09:47:27 +0000 [thread overview] Message-ID: <PH0PR11MB56586D2EC89F282C915AF18DC3879@PH0PR11MB5658.namprd11.prod.outlook.com> (raw) In-Reply-To: <20211025125309.GT2744544@nvidia.com> Hi Jason, > From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Monday, October 25, 2021 8:53 PM > > On Mon, Oct 25, 2021 at 06:28:09AM +0000, Liu, Yi L wrote: > > thanks for the guiding. will also refer to your vfio_group_cdev series. > > > > Need to double confirm here. Not quite following on the kfree. Is > > this kfree to free the vfio_device structure? But now the > > vfio_device pointer is provided by callers (e.g. vfio-pci). Do > > you want to let vfio core allocate the vfio_device struct and > > return the pointer to callers? > > There are several common patterns for this problem, two that would be > suitable: > > - Require each driver to provide a release op inside vfio_device_ops > that does the kfree. Have the core provide a struct device release > op that calls this one. Keep the kalloc/kfree in the drivers this way sees to suit the existing vfio registration manner listed below. right? But device drivers needs to do the kfree in the newly added release op instead of doing it on their own (e.g. doing kfree in remove). vfio_init_group_dev() vfio_register_group_dev() vfio_unregister_group_dev() vfio_uninit_group_dev() > - Move the kalloc into the core and have the core provide the kfree > with an optional release callback for anydriver specific cleanup > > This requires some macro to make the memory layout work. RDMA has > a version of this: > > struct ib_device *_ib_alloc_device(size_t size); > #define ib_alloc_device(drv_struct, member) \ > container_of(_ib_alloc_device(sizeof(struct drv_struct) + \ > BUILD_BUG_ON_ZERO(offsetof( \ > struct drv_struct, member))), \ > struct drv_struct, member) > thanks for the example. If this way, still requires driver to provide a release op inside vfio_device_ops. right? > In part the choice is how many drivers require a release callback > anyhow, if they all do then the first is easier to understand. If only > few or none do then the latter is less code in drivers, and never > exposes the driver to the tricky transition from alloc to refcount > cleanup. I'm not quite sure. But per my understanding, since the vfio_device is expected to be embedded in the device state struct (e.g. vfio_pci_core_device), I guess most of the drivers will require callback to do driver specific cleanup. Seems like option #1 may make sense? Regards, Yi Liu
WARNING: multiple messages have this Message-ID (diff)
From: "Liu, Yi L" <yi.l.liu@intel.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "jasowang@redhat.com" <jasowang@redhat.com>, "kwankhede@nvidia.com" <kwankhede@nvidia.com>, "hch@lst.de" <hch@lst.de>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "Jiang, Dave" <dave.jiang@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, "corbet@lwn.net" <corbet@lwn.net>, "Tian, Kevin" <kevin.tian@intel.com>, "parav@mellanox.com" <parav@mellanox.com>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "lkml@metux.net" <lkml@metux.net>, "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>, "dwmw2@infradead.org" <dwmw2@infradead.org>, "Tian, Jun J" <jun.j.tian@intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "lushenming@huawei.com" <lushenming@huawei.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "pbonzini@redhat.com" <pbonzini@redhat.com>, "robin.murphy@arm.com" <robin.murphy@arm.com> Subject: RE: [RFC 02/20] vfio: Add device class for /dev/vfio/devices Date: Fri, 29 Oct 2021 09:47:27 +0000 [thread overview] Message-ID: <PH0PR11MB56586D2EC89F282C915AF18DC3879@PH0PR11MB5658.namprd11.prod.outlook.com> (raw) In-Reply-To: <20211025125309.GT2744544@nvidia.com> Hi Jason, > From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Monday, October 25, 2021 8:53 PM > > On Mon, Oct 25, 2021 at 06:28:09AM +0000, Liu, Yi L wrote: > > thanks for the guiding. will also refer to your vfio_group_cdev series. > > > > Need to double confirm here. Not quite following on the kfree. Is > > this kfree to free the vfio_device structure? But now the > > vfio_device pointer is provided by callers (e.g. vfio-pci). Do > > you want to let vfio core allocate the vfio_device struct and > > return the pointer to callers? > > There are several common patterns for this problem, two that would be > suitable: > > - Require each driver to provide a release op inside vfio_device_ops > that does the kfree. Have the core provide a struct device release > op that calls this one. Keep the kalloc/kfree in the drivers this way sees to suit the existing vfio registration manner listed below. right? But device drivers needs to do the kfree in the newly added release op instead of doing it on their own (e.g. doing kfree in remove). vfio_init_group_dev() vfio_register_group_dev() vfio_unregister_group_dev() vfio_uninit_group_dev() > - Move the kalloc into the core and have the core provide the kfree > with an optional release callback for anydriver specific cleanup > > This requires some macro to make the memory layout work. RDMA has > a version of this: > > struct ib_device *_ib_alloc_device(size_t size); > #define ib_alloc_device(drv_struct, member) \ > container_of(_ib_alloc_device(sizeof(struct drv_struct) + \ > BUILD_BUG_ON_ZERO(offsetof( \ > struct drv_struct, member))), \ > struct drv_struct, member) > thanks for the example. If this way, still requires driver to provide a release op inside vfio_device_ops. right? > In part the choice is how many drivers require a release callback > anyhow, if they all do then the first is easier to understand. If only > few or none do then the latter is less code in drivers, and never > exposes the driver to the tricky transition from alloc to refcount > cleanup. I'm not quite sure. But per my understanding, since the vfio_device is expected to be embedded in the device state struct (e.g. vfio_pci_core_device), I guess most of the drivers will require callback to do driver specific cleanup. Seems like option #1 may make sense? Regards, Yi Liu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-10-29 9:47 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-25 6:28 [RFC 02/20] vfio: Add device class for /dev/vfio/devices Liu, Yi L 2021-10-25 12:53 ` Jason Gunthorpe 2021-10-25 12:53 ` Jason Gunthorpe via iommu 2021-10-29 9:47 ` Liu, Yi L [this message] 2021-10-29 9:47 ` Liu, Yi L 2021-11-01 12:50 ` Jason Gunthorpe 2021-11-01 12:50 ` Jason Gunthorpe via iommu 2021-11-02 9:53 ` Liu, Yi L 2021-11-02 9:53 ` Liu, Yi L 2021-11-03 13:25 ` Jason Gunthorpe 2021-11-03 13:25 ` Jason Gunthorpe via iommu 2021-11-11 12:32 ` Liu, Yi L 2021-11-11 12:32 ` Liu, Yi L -- strict thread matches above, loose matches on Subject: below -- 2021-09-19 6:38 [RFC 00/20] Introduce /dev/iommu for userspace I/O address space management Liu Yi L 2021-09-19 6:38 ` [RFC 02/20] vfio: Add device class for /dev/vfio/devices Liu Yi L 2021-09-19 6:38 ` Liu Yi L 2021-09-21 15:57 ` Jason Gunthorpe 2021-09-21 15:57 ` Jason Gunthorpe via iommu 2021-09-21 23:56 ` Tian, Kevin 2021-09-21 23:56 ` Tian, Kevin 2021-09-22 0:55 ` Jason Gunthorpe 2021-09-22 0:55 ` Jason Gunthorpe via iommu 2021-09-22 1:07 ` Tian, Kevin 2021-09-22 1:07 ` Tian, Kevin 2021-09-22 12:31 ` Jason Gunthorpe 2021-09-22 12:31 ` Jason Gunthorpe via iommu 2021-09-22 3:22 ` Tian, Kevin 2021-09-22 3:22 ` Tian, Kevin 2021-09-22 12:50 ` Jason Gunthorpe 2021-09-22 12:50 ` Jason Gunthorpe via iommu 2021-09-22 14:09 ` Tian, Kevin 2021-09-22 14:09 ` Tian, Kevin 2021-09-21 19:56 ` Alex Williamson 2021-09-21 19:56 ` Alex Williamson 2021-09-22 0:56 ` Tian, Kevin 2021-09-22 0:56 ` Tian, Kevin 2021-09-29 2:08 ` David Gibson 2021-09-29 2:08 ` David Gibson 2021-09-29 19:05 ` Alex Williamson 2021-09-29 19:05 ` Alex Williamson 2021-09-30 2:43 ` David Gibson 2021-09-30 2:43 ` David Gibson 2021-10-20 12:39 ` Liu, Yi L 2021-10-20 12:39 ` 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=PH0PR11MB56586D2EC89F282C915AF18DC3879@PH0PR11MB5658.namprd11.prod.outlook.com \ --to=yi.l.liu@intel.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=corbet@lwn.net \ --cc=dave.jiang@intel.com \ --cc=david@gibson.dropbear.id.au \ --cc=dwmw2@infradead.org \ --cc=eric.auger@redhat.com \ --cc=hao.wu@intel.com \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@linux.intel.com \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=jgg@nvidia.com \ --cc=joro@8bytes.org \ --cc=jun.j.tian@intel.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lkml@metux.net \ --cc=lushenming@huawei.com \ --cc=nicolinc@nvidia.com \ --cc=parav@mellanox.com \ --cc=pbonzini@redhat.com \ --cc=robin.murphy@arm.com \ --cc=yi.l.liu@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.