From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"lulu@redhat.com" <lulu@redhat.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 3/6] iommufd: Add IOMMU_DEVICE_GET_INFO
Date: Fri, 10 Feb 2023 16:59:51 -0400 [thread overview]
Message-ID: <Y+awR7UO6R2FzHiV@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276F92ABD5998FDD74D510A8CDE9@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Feb 10, 2023 at 07:55:42AM +0000, Tian, Kevin wrote:
> > From: Liu, Yi L <yi.l.liu@intel.com>
> > Sent: Thursday, February 9, 2023 12:17 PM
> >
> > +int iommufd_device_get_info(struct iommufd_ucmd *ucmd)
> > +{
> > + struct iommu_device_info *cmd = ucmd->cmd;
> > + struct iommufd_object *dev_obj;
> > + struct device *dev;
> > + const struct iommu_ops *ops;
> > + void *data;
> > + unsigned int length, data_len;
> > + int rc;
> > +
> > + if (cmd->flags || cmd->__reserved || !cmd->data_len)
> > + return -EOPNOTSUPP;
>
> do we want !cmd->data_len being a way to check how many bytes are
> required in a following call to get the vendor info?
There is no reason, if the userspace doesn't have a struct large
enough then it also doesn't know what the extra bytes should even be
used for. No reason to read the.
> > +struct iommu_device_info {
> > + __u32 size;
> > + __u32 flags;
> > + __u32 dev_id;
> > + __u32 data_len;
> > + __aligned_u64 data_ptr;
>
> moving forward iommu hw cap is not the only information reported
> via this interface, e.g. it can be also used to report pasid mode.
>
> from this angle it's better to rename above two fields to be iommu
> specific, e.g.:
>
> __u32 iommu_data_len;
> __aligned_u64 iommu_data_ptr;
maybe call it hw info
Jason
next prev parent reply other threads:[~2023-02-10 20:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 4:16 [PATCH 0/6] iommufd: Add iommu capability reporting Yi Liu
2023-02-09 4:16 ` [PATCH 1/6] iommu: Add new iommu op to get iommu hardware information Yi Liu
2023-02-10 7:28 ` Tian, Kevin
2023-02-11 3:38 ` Baolu Lu
2023-02-11 3:42 ` Baolu Lu
2023-02-13 1:54 ` Tian, Kevin
2023-02-13 2:36 ` Binbin Wu
2023-02-13 8:46 ` Baolu Lu
2023-02-09 4:16 ` [PATCH 2/6] iommu/vt-d: Implement hw_info for iommu capability query Yi Liu
2023-02-10 7:32 ` Tian, Kevin
2023-02-11 3:45 ` Baolu Lu
2023-02-10 22:44 ` Alex Williamson
2023-02-11 0:15 ` Jason Gunthorpe
2023-02-13 3:09 ` Binbin Wu
2023-02-13 8:48 ` Baolu Lu
2023-02-13 14:51 ` Jason Gunthorpe
2023-02-09 4:16 ` [PATCH 3/6] iommufd: Add IOMMU_DEVICE_GET_INFO Yi Liu
2023-02-10 7:55 ` Tian, Kevin
2023-02-10 11:10 ` Joao Martins
2023-02-10 20:58 ` Jason Gunthorpe
2023-02-10 20:59 ` Jason Gunthorpe [this message]
2023-02-13 2:04 ` Tian, Kevin
2023-02-09 4:16 ` [PATCH 4/6] iommufd/device: Add mock_device support in iommufd_device_get_info() Yi Liu
2023-02-09 4:16 ` [PATCH 5/6] iommufd/selftest: Set iommu_device for mock_device Yi Liu
2023-02-09 4:16 ` [PATCH 6/6] iommufd/selftest: Add coverage for IOMMU_DEVICE_GET_INFO ioctl Yi Liu
2023-02-22 21:07 ` [PATCH 0/6] iommufd: Add iommu capability reporting Jason Gunthorpe
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=Y+awR7UO6R2FzHiV@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=chao.p.peng@linux.intel.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suravee.suthikulpanit@amd.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 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.