From: "Liu, Yi L" <yi.l.liu@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Tian, Jun J" <jun.j.tian@intel.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Sun, Yi Y" <yi.y.sun@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
"Lu, Baolu" <baolu.lu@intel.com>
Subject: RE: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to host
Date: Thu, 5 Dec 2019 12:19:14 +0000 [thread overview]
Message-ID: <A2975661238FB949B60364EF0F2C25743A126B1A@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <20191202171149.12092335@x1.home>
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Tuesday, December 3, 2019 8:12 AM
> To: Liu, Yi L <yi.l.liu@intel.com>
> Subject: Re: [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to host
>
> On Mon, 25 Nov 2019 07:45:18 +0000
> "Liu, Yi L" <yi.l.liu@intel.com> wrote:
>
> > Hi Alex,
> >
> > Thanks for the review. Here I'd like to conclude the major opens in this
> > thread and see if we can get some agreements to prepare a new version.
> >
> > a) IOCTLs for BIND_GPASID and BIND_PROCESS, share a single IOCTL or two
> > separate IOCTLs?
> > Yi: It may be helpful to have separate IOCTLs. The bind data conveyed
> > for BIND_GPASID and BIND_PROCESS are totally different, and the struct
> > iommu_gpasid_bind_data has vendor specific data and may even have more
> > versions in future. To better maintain it, I guess separate IOCTLs for
> > the two bind types would be better. The structure for BIND_GPASID is
> > as below:
> >
> > struct vfio_iommu_type1_bind {
> > __u32 argsz;
> > struct iommu_gpasid_bind_data bind_data;
> > };
>
>
> We've been rather successful at extending ioctls in vfio and I'm
> generally opposed to rampant ioctl proliferation. If we added @flags
> to the above struct (as pretty much the standard for vfio ioctls), then
> we could use it to describe the type of binding to perform and
> therefore the type of data provided. I think my major complaint here
> was that we were defining PROCESS but not implementing it. We can
> design the ioctl to enable it, but not define it until it's implemented.
sure, so I'll pull back the @flags field. BTW. Regards to the payloads,
what would be preferred? @data[] or a wrapper structure like below?
union {
struct iommu_gpasid_bind_data bind_gpasid;
}bind_data;
> > b) how kernel-space learns the number of bytes to be copied (a.k.a. the
> > usage of @version field and @format field of struct
> > iommu_gpasid_bind_data)
> > Yi: Jean has an excellent recap in prior reply on the plan of future
> > extensions regards to @version field and @format field. Based on the
> > plan, kernel space needs to parse the @version field and @format field
> > to get the length of the current BIND_GPASID request. Also kernel needs
> > to maintain the new and old structure versions. Follow specific
> > deprecation policy in future.
>
> Yes, it seems reasonable, so from the struct above (plus @flags) we
> could determine we have struct iommu_gpasid_bind_data as the payload
> and read that using @version and @format as outlined.
sure, thanks.
> > c) how can vIOMMU emulator know that the vfio interface supports to config
> > dual stage translation for vIOMMU?
> > Yi: may do it via VFIO_IOMMU_GET_INFO.
>
> Yes please.
got it.
> > d) how can vIOMMU emulator know what @version and @format should be set
> > in struct iommu_gpasid_bind_data?
> > Yi: currently, we have two ways. First one, may do it via
> > VFIO_IOMMU_GET_INFO. This is a natural idea as here @version and @format
> > are used in vfio apis. It makes sense to let vfio to provide related info
> > to vIOMMU emulator after checking with vendor specific iommu driver. Also,
> > there is idea to do it via sysfs (/sys/class/iommu/dmar#) as we have plan
> > to do IOMMU capability sync between vIOMMU and pIOMMU via sysfs. I have
> > two concern on this option. Current iommu sysfs only provides vendor
> > specific hardware infos. I'm not sure if it is good to expose infos
> > defined in IOMMU generic layer via iommu sysfs. If this concern is not
> > a big thing, I'm fine with both options.
>
> This seems like the same issue we had with IOMMU reserved regions, I'd
> prefer that a user can figure out how to interact with the vfio
> interface through the vfio interface. Forcing the user to poke around
> in sysfs requires the user to have read permissions to sysfs in places
> they otherwise wouldn't need. Thanks,
thanks, let me prepare a new version.
Regards,
Yi Liu
> Alex
next prev parent reply other threads:[~2019-12-05 12:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 12:26 [RFC v2 0/3] vfio: support Shared Virtual Addressing Liu Yi L
2019-10-24 12:26 ` [RFC v2 1/3] vfio: VFIO_IOMMU_CACHE_INVALIDATE Liu Yi L
2019-10-25 9:14 ` Tian, Kevin
2019-10-25 11:20 ` Liu, Yi L
2019-11-05 22:42 ` Alex Williamson
2019-11-06 1:31 ` Liu, Yi L
2019-11-13 7:50 ` Auger Eric
2019-10-24 12:26 ` [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free) Liu Yi L
2019-10-25 10:06 ` Tian, Kevin
2019-10-25 11:16 ` Liu, Yi L
2019-11-05 23:35 ` Alex Williamson
2019-11-06 13:27 ` Liu, Yi L
2019-11-07 22:06 ` Alex Williamson
2019-11-08 12:23 ` Liu, Yi L
2019-11-08 15:15 ` Alex Williamson
2019-11-13 11:03 ` Liu, Yi L
2019-11-13 15:29 ` Alex Williamson
2019-11-13 19:45 ` Jacob Pan
2019-11-25 8:32 ` Liu, Yi L
2019-11-18 4:50 ` Liu, Yi L
2019-10-24 12:26 ` [RFC v2 3/3] vfio/type1: bind guest pasid (guest page tables) to host Liu Yi L
2019-11-07 23:20 ` Alex Williamson
2019-11-12 11:21 ` Liu, Yi L
2019-11-12 17:25 ` Alex Williamson
2019-11-13 7:43 ` Liu, Yi L
2019-11-13 10:29 ` Jean-Philippe Brucker
2019-11-13 11:30 ` Liu, Yi L
2019-11-25 7:45 ` Liu, Yi L
2019-12-03 0:11 ` Alex Williamson
2019-12-05 12:19 ` Liu, Yi L [this message]
2019-10-25 8:59 ` [RFC v2 0/3] vfio: support Shared Virtual Addressing Tian, Kevin
2019-10-25 11:18 ` 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=A2975661238FB949B60364EF0F2C25743A126B1A@SHSMSX104.ccr.corp.intel.com \
--to=yi.l.liu@intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@intel.com \
--cc=eric.auger@redhat.com \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.org \
--cc=jun.j.tian@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=yi.y.sun@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;
as well as URLs for NNTP newsgroup(s).