From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"stefanha@gmail.com" <stefanha@gmail.com>,
"Sun, Yi Y" <yi.y.sun@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>, "Wu, Hao" <hao.wu@intel.com>,
"Tian, Jun J" <jun.j.tian@intel.com>
Subject: Re: [PATCH v6 02/15] iommu: Report domain nesting info
Date: Mon, 17 Aug 2020 21:21:52 -0700 [thread overview]
Message-ID: <20200817212152.2820eedd@jacob-builder> (raw)
In-Reply-To: <342e8d77-1c1d-e637-0227-720ba67df8ba@redhat.com>
On Sun, 16 Aug 2020 14:40:57 +0200
Auger Eric <eric.auger@redhat.com> wrote:
> Hi Yi,
>
> On 8/14/20 9:15 AM, Liu, Yi L wrote:
> > Hi Eric,
> >
> >> From: Auger Eric <eric.auger@redhat.com>
> >> Sent: Thursday, August 13, 2020 8:53 PM
> >>
> >> Yi,
> >> On 7/28/20 8:27 AM, Liu Yi L wrote:
> >>> IOMMUs that support nesting translation needs report the
> >>> capability info
> >> s/needs/need to
> >>> to userspace. It gives information about requirements the
> >>> userspace needs to implement plus other features characterizing
> >>> the physical implementation.
> >>>
> >>> This patch reports nesting info by DOMAIN_ATTR_NESTING. Caller
> >>> can get nesting info after setting DOMAIN_ATTR_NESTING. For VFIO,
> >>> it is after selecting VFIO_TYPE1_NESTING_IOMMU.
> >> This is not what this patch does ;-) It introduces a new IOMMU UAPI
> >> struct that gives information about the nesting capabilities and
> >> features. This struct is supposed to be returned by
> >> iommu_domain_get_attr() with DOMAIN_ATTR_NESTING attribute
> >> parameter, one a domain whose type has been set to
> >> DOMAIN_ATTR_NESTING.
> >
> > got it. let me apply your suggestion. thanks. :-)
> >
> >>>
> >>> Cc: Kevin Tian <kevin.tian@intel.com>
> >>> CC: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>> Cc: Eric Auger <eric.auger@redhat.com>
> >>> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
> >>> Cc: Joerg Roedel <joro@8bytes.org>
> >>> Cc: Lu Baolu <baolu.lu@linux.intel.com>
> >>> Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> >>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >>> ---
> >>> v5 -> v6:
> >>> *) rephrase the feature notes per comments from Eric Auger.
> >>> *) rename @size of struct iommu_nesting_info to @argsz.
> >>>
> >>> v4 -> v5:
> >>> *) address comments from Eric Auger.
> >>>
> >>> v3 -> v4:
> >>> *) split the SMMU driver changes to be a separate patch
> >>> *) move the @addr_width and @pasid_bits from vendor specific
> >>> part to generic part.
> >>> *) tweak the description for the @features field of struct
> >>> iommu_nesting_info.
> >>> *) add description on the @data[] field of struct
> >>> iommu_nesting_info
> >>>
> >>> v2 -> v3:
> >>> *) remvoe cap/ecap_mask in iommu_nesting_info.
> >>> *) reuse DOMAIN_ATTR_NESTING to get nesting info.
> >>> *) return an empty iommu_nesting_info for SMMU drivers per Jean'
> >>> suggestion.
> >>> ---
> >>> include/uapi/linux/iommu.h | 74
> >> ++++++++++++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 74 insertions(+)
> >>>
> >>> diff --git a/include/uapi/linux/iommu.h
> >>> b/include/uapi/linux/iommu.h index 7c8e075..5e4745a 100644
> >>> --- a/include/uapi/linux/iommu.h
> >>> +++ b/include/uapi/linux/iommu.h
> >>> @@ -332,4 +332,78 @@ struct iommu_gpasid_bind_data {
> >>> } vendor;
> >>> };
> >>>
> >>> +/*
> >>> + * struct iommu_nesting_info - Information for nesting-capable
> >>> IOMMU.
> >>> + * userspace should check it
> >>> before using
> >>> + * nesting capability.
> >>> + *
> >>> + * @argsz: size of the whole structure.
> >>> + * @flags: currently reserved for future extension. must
> >>> set to 0.
> >>> + * @format: PASID table entry format, the same definition
> >>> as struct
> >>> + * iommu_gpasid_bind_data @format.
> >>> + * @features: supported nesting features.
> >>> + * @addr_width: The output addr width of first
> >>> level/stage translation
> >>> + * @pasid_bits: Maximum supported PASID bits, 0
> >>> represents no PASID
> >>> + * support.
> >>> + * @data: vendor specific cap info. data[] structure type
> >>> can be deduced
> >>> + * from @format field.
> >>> + *
> >>> + *
> >> +===============+===================================================
> >> ===+
> >>> + * | feature |
> >>> Notes |
> >>> + *
> >> +===============+===================================================
> >> ===+
> >>> + * | SYSWIDE_PASID | IOMMU vendor driver sets it to mandate
> >>> userspace |
> >>> + * | | to allocate PASID from kernel. All PASID
> >>> allocation |
> >>> + * | | free must be mediated through the TBD
> >>> API. |
> >> s/TBD/IOMMU
> >
> > got it.
> >
> >>> + *
> >>> +---------------+------------------------------------------------------+
> >>> + * | BIND_PGTBL | IOMMU vendor driver sets it to mandate
> >>> userspace |
> >>> + * | | bind the first level/stage page table to
> >>> associated |
> >> s/bind/to bind
> >
> > got it.
> >
> >>> + * | | PASID (either the one specified in bind
> >>> request or |
> >>> + * | | the default PASID of iommu domain),
> >>> through IOMMU |
> >>> + * | |
> >>> UAPI. |
> >>> + *
> >>> +---------------+------------------------------------------------------+
> >>> + * | CACHE_INVLD | IOMMU vendor driver sets it to mandate
> >>> userspace |
> >>
> >>> + * | | explicitly invalidate the IOMMU cache
> >>> through IOMMU |
> >> to explicitly
> >
> > I see.
> >
> >>> + * | | U
> >>> API according to vendor-specific requirement when |
> >>> + * | | changing the 1st level/stage page
> >>> table. |
> >>> + *
> >>> +---------------+------------------------------------------------------+
> >>> + *
> >>> + * @data[] types defined for @format:
> >>> + *
> >> +================================+==================================
> >> ===+
> >>> + * | @format |
> >>> @data[] |
> >>> + *
> >> +================================+==================================
> >> ===+
> >>> + * | IOMMU_PASID_FORMAT_INTEL_VTD | struct
> >>> iommu_nesting_info_vtd |
> >>> + *
> >>> +--------------------------------+-------------------------------------+
> >>> + *
> >>> + */
> >>> +struct iommu_nesting_info {
> >>> + __u32 argsz;
> >>> + __u32 flags;
> >>> + __u32 format;
> >>> +#define IOMMU_NESTING_FEAT_SYSWIDE_PASID (1 << 0)
> >>> +#define IOMMU_NESTING_FEAT_BIND_PGTBL (1 << 1)
> >>> +#define IOMMU_NESTING_FEAT_CACHE_INVLD (1 << 2)
> >>> + __u32 features;
> >>> + __u16 addr_width;
> >>> + __u16 pasid_bits;
> >>> + __u32 padding;
> >>> + __u8 data[];
> >>> +};
> >> As opposed to other IOMMU UAPI structs there is no union member at
> >> the end.
> >
> > nice catch. do you think it would be better to adding a union and
> > put the struct iommu_nesting_info_vtd in it?
> Yes I think so. At least it would be consistent with the rest of the
> API and with the guidelines.
> >
> >> Also this struct is not documented in [PATCH v7 1/7] docs: IOMMU
> >> user API. Shouldn't we align.
> >> You may also consider to move this patch in Jacob's series for
> >> consistency, thoughts?
> >
> > this was talked one time between Jacob and me. It was put in this
> > series as the major user of nesting_info is in this series. e.g.
> > vfio checks the SYSWIDE_PASID. but I'm open to merge it with Jacob's
> > series if it would make the merge easier.
> Yep I think it would make sense to move in Jacob's series to have a
> general understanding of the uapi
>
I a little reluctant to include this in my UAPI set, the reason is that
there are two dimensions IOMMU UAPI are extended:
1. Define the protocols in interaction with VFIO, sanity checking, and
backward compatibility.
2. Adding more UAPI data structures that are parallel to the existing
ones.
My patchset is to address #1, this patch is for #2. My thinking is that
once we have reached consensus on #1, new UAPI structures such as this
patch can just follow the suit.
If that is OK with you, I would like to keep them separate to avoid
diverging conversations.
Thanks,
Jacob
> Thanks
>
> Eric
> >
> > Thanks,
> > Yi Liu
> >
> >>> +
> >>> +/*
> >>> + * struct iommu_nesting_info_vtd - Intel VT-d specific nesting
> >>> info.
> >>> + *
> >>> + * @flags: VT-d specific flags. Currently reserved for
> >>> future
> >>> + * extension. must be set to 0.
> >>> + * @cap_reg: Describe basic capabilities as defined in
> >>> VT-d capability
> >>> + * register.
> >>> + * @ecap_reg: Describe the extended capabilities as
> >>> defined in VT-d
> >>> + * extended capability register.
> >>> + */
> >>> +struct iommu_nesting_info_vtd {
> >>> + __u32 flags;
> >>> + __u32 padding;
> >>> + __u64 cap_reg;
> >>> + __u64 ecap_reg;
> >>> +};
> >>> +
> >>> #endif /* _UAPI_IOMMU_H */
> >>>
> >>
> >> Thanks
> >>
> >> Eric
> >>
> >
>
[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Tian, Jun J" <jun.j.tian@intel.com>,
"Sun, Yi Y" <yi.y.sun@intel.com>,
"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"peterx@redhat.com" <peterx@redhat.com>,
"Wu, Hao" <hao.wu@intel.com>,
"stefanha@gmail.com" <stefanha@gmail.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH v6 02/15] iommu: Report domain nesting info
Date: Mon, 17 Aug 2020 21:21:52 -0700 [thread overview]
Message-ID: <20200817212152.2820eedd@jacob-builder> (raw)
In-Reply-To: <342e8d77-1c1d-e637-0227-720ba67df8ba@redhat.com>
On Sun, 16 Aug 2020 14:40:57 +0200
Auger Eric <eric.auger@redhat.com> wrote:
> Hi Yi,
>
> On 8/14/20 9:15 AM, Liu, Yi L wrote:
> > Hi Eric,
> >
> >> From: Auger Eric <eric.auger@redhat.com>
> >> Sent: Thursday, August 13, 2020 8:53 PM
> >>
> >> Yi,
> >> On 7/28/20 8:27 AM, Liu Yi L wrote:
> >>> IOMMUs that support nesting translation needs report the
> >>> capability info
> >> s/needs/need to
> >>> to userspace. It gives information about requirements the
> >>> userspace needs to implement plus other features characterizing
> >>> the physical implementation.
> >>>
> >>> This patch reports nesting info by DOMAIN_ATTR_NESTING. Caller
> >>> can get nesting info after setting DOMAIN_ATTR_NESTING. For VFIO,
> >>> it is after selecting VFIO_TYPE1_NESTING_IOMMU.
> >> This is not what this patch does ;-) It introduces a new IOMMU UAPI
> >> struct that gives information about the nesting capabilities and
> >> features. This struct is supposed to be returned by
> >> iommu_domain_get_attr() with DOMAIN_ATTR_NESTING attribute
> >> parameter, one a domain whose type has been set to
> >> DOMAIN_ATTR_NESTING.
> >
> > got it. let me apply your suggestion. thanks. :-)
> >
> >>>
> >>> Cc: Kevin Tian <kevin.tian@intel.com>
> >>> CC: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>> Cc: Eric Auger <eric.auger@redhat.com>
> >>> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
> >>> Cc: Joerg Roedel <joro@8bytes.org>
> >>> Cc: Lu Baolu <baolu.lu@linux.intel.com>
> >>> Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
> >>> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> >>> ---
> >>> v5 -> v6:
> >>> *) rephrase the feature notes per comments from Eric Auger.
> >>> *) rename @size of struct iommu_nesting_info to @argsz.
> >>>
> >>> v4 -> v5:
> >>> *) address comments from Eric Auger.
> >>>
> >>> v3 -> v4:
> >>> *) split the SMMU driver changes to be a separate patch
> >>> *) move the @addr_width and @pasid_bits from vendor specific
> >>> part to generic part.
> >>> *) tweak the description for the @features field of struct
> >>> iommu_nesting_info.
> >>> *) add description on the @data[] field of struct
> >>> iommu_nesting_info
> >>>
> >>> v2 -> v3:
> >>> *) remvoe cap/ecap_mask in iommu_nesting_info.
> >>> *) reuse DOMAIN_ATTR_NESTING to get nesting info.
> >>> *) return an empty iommu_nesting_info for SMMU drivers per Jean'
> >>> suggestion.
> >>> ---
> >>> include/uapi/linux/iommu.h | 74
> >> ++++++++++++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 74 insertions(+)
> >>>
> >>> diff --git a/include/uapi/linux/iommu.h
> >>> b/include/uapi/linux/iommu.h index 7c8e075..5e4745a 100644
> >>> --- a/include/uapi/linux/iommu.h
> >>> +++ b/include/uapi/linux/iommu.h
> >>> @@ -332,4 +332,78 @@ struct iommu_gpasid_bind_data {
> >>> } vendor;
> >>> };
> >>>
> >>> +/*
> >>> + * struct iommu_nesting_info - Information for nesting-capable
> >>> IOMMU.
> >>> + * userspace should check it
> >>> before using
> >>> + * nesting capability.
> >>> + *
> >>> + * @argsz: size of the whole structure.
> >>> + * @flags: currently reserved for future extension. must
> >>> set to 0.
> >>> + * @format: PASID table entry format, the same definition
> >>> as struct
> >>> + * iommu_gpasid_bind_data @format.
> >>> + * @features: supported nesting features.
> >>> + * @addr_width: The output addr width of first
> >>> level/stage translation
> >>> + * @pasid_bits: Maximum supported PASID bits, 0
> >>> represents no PASID
> >>> + * support.
> >>> + * @data: vendor specific cap info. data[] structure type
> >>> can be deduced
> >>> + * from @format field.
> >>> + *
> >>> + *
> >> +===============+===================================================
> >> ===+
> >>> + * | feature |
> >>> Notes |
> >>> + *
> >> +===============+===================================================
> >> ===+
> >>> + * | SYSWIDE_PASID | IOMMU vendor driver sets it to mandate
> >>> userspace |
> >>> + * | | to allocate PASID from kernel. All PASID
> >>> allocation |
> >>> + * | | free must be mediated through the TBD
> >>> API. |
> >> s/TBD/IOMMU
> >
> > got it.
> >
> >>> + *
> >>> +---------------+------------------------------------------------------+
> >>> + * | BIND_PGTBL | IOMMU vendor driver sets it to mandate
> >>> userspace |
> >>> + * | | bind the first level/stage page table to
> >>> associated |
> >> s/bind/to bind
> >
> > got it.
> >
> >>> + * | | PASID (either the one specified in bind
> >>> request or |
> >>> + * | | the default PASID of iommu domain),
> >>> through IOMMU |
> >>> + * | |
> >>> UAPI. |
> >>> + *
> >>> +---------------+------------------------------------------------------+
> >>> + * | CACHE_INVLD | IOMMU vendor driver sets it to mandate
> >>> userspace |
> >>
> >>> + * | | explicitly invalidate the IOMMU cache
> >>> through IOMMU |
> >> to explicitly
> >
> > I see.
> >
> >>> + * | | U
> >>> API according to vendor-specific requirement when |
> >>> + * | | changing the 1st level/stage page
> >>> table. |
> >>> + *
> >>> +---------------+------------------------------------------------------+
> >>> + *
> >>> + * @data[] types defined for @format:
> >>> + *
> >> +================================+==================================
> >> ===+
> >>> + * | @format |
> >>> @data[] |
> >>> + *
> >> +================================+==================================
> >> ===+
> >>> + * | IOMMU_PASID_FORMAT_INTEL_VTD | struct
> >>> iommu_nesting_info_vtd |
> >>> + *
> >>> +--------------------------------+-------------------------------------+
> >>> + *
> >>> + */
> >>> +struct iommu_nesting_info {
> >>> + __u32 argsz;
> >>> + __u32 flags;
> >>> + __u32 format;
> >>> +#define IOMMU_NESTING_FEAT_SYSWIDE_PASID (1 << 0)
> >>> +#define IOMMU_NESTING_FEAT_BIND_PGTBL (1 << 1)
> >>> +#define IOMMU_NESTING_FEAT_CACHE_INVLD (1 << 2)
> >>> + __u32 features;
> >>> + __u16 addr_width;
> >>> + __u16 pasid_bits;
> >>> + __u32 padding;
> >>> + __u8 data[];
> >>> +};
> >> As opposed to other IOMMU UAPI structs there is no union member at
> >> the end.
> >
> > nice catch. do you think it would be better to adding a union and
> > put the struct iommu_nesting_info_vtd in it?
> Yes I think so. At least it would be consistent with the rest of the
> API and with the guidelines.
> >
> >> Also this struct is not documented in [PATCH v7 1/7] docs: IOMMU
> >> user API. Shouldn't we align.
> >> You may also consider to move this patch in Jacob's series for
> >> consistency, thoughts?
> >
> > this was talked one time between Jacob and me. It was put in this
> > series as the major user of nesting_info is in this series. e.g.
> > vfio checks the SYSWIDE_PASID. but I'm open to merge it with Jacob's
> > series if it would make the merge easier.
> Yep I think it would make sense to move in Jacob's series to have a
> general understanding of the uapi
>
I a little reluctant to include this in my UAPI set, the reason is that
there are two dimensions IOMMU UAPI are extended:
1. Define the protocols in interaction with VFIO, sanity checking, and
backward compatibility.
2. Adding more UAPI data structures that are parallel to the existing
ones.
My patchset is to address #1, this patch is for #2. My thinking is that
once we have reached consensus on #1, new UAPI structures such as this
patch can just follow the suit.
If that is OK with you, I would like to keep them separate to avoid
diverging conversations.
Thanks,
Jacob
> Thanks
>
> Eric
> >
> > Thanks,
> > Yi Liu
> >
> >>> +
> >>> +/*
> >>> + * struct iommu_nesting_info_vtd - Intel VT-d specific nesting
> >>> info.
> >>> + *
> >>> + * @flags: VT-d specific flags. Currently reserved for
> >>> future
> >>> + * extension. must be set to 0.
> >>> + * @cap_reg: Describe basic capabilities as defined in
> >>> VT-d capability
> >>> + * register.
> >>> + * @ecap_reg: Describe the extended capabilities as
> >>> defined in VT-d
> >>> + * extended capability register.
> >>> + */
> >>> +struct iommu_nesting_info_vtd {
> >>> + __u32 flags;
> >>> + __u32 padding;
> >>> + __u64 cap_reg;
> >>> + __u64 ecap_reg;
> >>> +};
> >>> +
> >>> #endif /* _UAPI_IOMMU_H */
> >>>
> >>
> >> Thanks
> >>
> >> Eric
> >>
> >
>
[Jacob Pan]
next prev parent reply other threads:[~2020-08-18 4:15 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 6:27 [PATCH v6 00/15] vfio: expose virtual Shared Virtual Addressing to VMs Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-07-28 6:27 ` [PATCH v6 01/15] vfio/type1: Refactor vfio_iommu_type1_ioctl() Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-07-28 15:53 ` Alex Williamson
2020-07-28 15:53 ` Alex Williamson
2020-07-29 2:20 ` Liu, Yi L
2020-07-29 2:20 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 02/15] iommu: Report domain nesting info Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-13 12:52 ` Auger Eric
2020-08-13 12:52 ` Auger Eric
2020-08-14 7:15 ` Liu, Yi L
2020-08-14 7:15 ` Liu, Yi L
2020-08-16 12:40 ` Auger Eric
2020-08-16 12:40 ` Auger Eric
2020-08-18 4:21 ` Jacob Pan [this message]
2020-08-18 4:21 ` Jacob Pan
2020-08-18 6:59 ` Auger Eric
2020-08-18 6:59 ` Auger Eric
2020-07-28 6:27 ` [PATCH v6 03/15] iommu/smmu: Report empty " Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-07-28 6:27 ` [PATCH v6 04/15] vfio/type1: Report iommu nesting info to userspace Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-13 13:19 ` Auger Eric
2020-08-13 13:19 ` Auger Eric
2020-08-14 7:36 ` Liu, Yi L
2020-08-14 7:36 ` Liu, Yi L
2020-08-20 19:52 ` Alex Williamson
2020-08-20 19:52 ` Alex Williamson
2020-08-21 0:52 ` Liu, Yi L
2020-08-21 0:52 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 05/15] vfio: Add PASID allocation/free support Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-13 15:07 ` Auger Eric
2020-08-13 15:07 ` Auger Eric
2020-08-14 7:40 ` Liu, Yi L
2020-08-14 7:40 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 06/15] iommu/vt-d: Support setting ioasid set to domain Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-13 15:06 ` Auger Eric
2020-08-13 15:06 ` Auger Eric
2020-08-14 8:04 ` Liu, Yi L
2020-08-14 8:04 ` Liu, Yi L
2020-08-16 12:42 ` Auger Eric
2020-08-16 12:42 ` Auger Eric
2020-07-28 6:27 ` [PATCH v6 07/15] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free) Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-15 16:30 ` Auger Eric
2020-08-15 16:30 ` Auger Eric
2020-08-17 5:23 ` Liu, Yi L
2020-08-17 5:23 ` Liu, Yi L
2020-08-20 20:51 ` Alex Williamson
2020-08-20 20:51 ` Alex Williamson
2020-08-21 0:37 ` Liu, Yi L
2020-08-21 0:37 ` Liu, Yi L
2020-08-21 1:49 ` Alex Williamson
2020-08-21 1:49 ` Alex Williamson
2020-08-21 2:18 ` Liu, Yi L
2020-08-21 2:18 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 08/15] iommu: Pass domain to sva_unbind_gpasid() Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-20 21:06 ` Alex Williamson
2020-08-20 21:06 ` Alex Williamson
2020-08-21 0:18 ` Liu, Yi L
2020-08-21 0:18 ` Liu, Yi L
2020-08-21 13:09 ` Auger Eric
2020-08-21 13:09 ` Auger Eric
2020-07-28 6:27 ` [PATCH v6 09/15] iommu/vt-d: Check ownership for PASIDs from user-space Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-15 16:30 ` Auger Eric
2020-08-15 16:30 ` Auger Eric
2020-08-17 5:38 ` Liu, Yi L
2020-08-17 5:38 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 10/15] vfio/type1: Support binding guest page tables to PASID Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-16 11:29 ` Auger Eric
2020-08-16 11:29 ` Auger Eric
2020-08-17 6:30 ` Liu, Yi L
2020-08-17 6:30 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 11/15] vfio/type1: Allow invalidating first-level/stage IOMMU cache Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-16 11:35 ` Auger Eric
2020-08-16 11:35 ` Auger Eric
2020-08-17 6:30 ` Liu, Yi L
2020-08-17 6:30 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 12/15] vfio/type1: Add vSVA support for IOMMU-backed mdevs Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-20 21:48 ` Alex Williamson
2020-08-20 21:48 ` Alex Williamson
2020-08-21 0:53 ` Liu, Yi L
2020-08-21 0:53 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 13/15] vfio/pci: Expose PCIe PASID capability to guest Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-07-28 6:27 ` [PATCH v6 14/15] vfio: Document dual stage control Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-16 11:51 ` Auger Eric
2020-08-16 11:51 ` Auger Eric
2020-08-17 7:00 ` Liu, Yi L
2020-08-17 7:00 ` Liu, Yi L
2020-08-17 7:40 ` Eric Auger
2020-08-17 7:40 ` Eric Auger
2020-08-17 7:43 ` Liu, Yi L
2020-08-17 7:43 ` Liu, Yi L
2020-07-28 6:27 ` [PATCH v6 15/15] iommu/vt-d: Support reporting nesting capability info Liu Yi L
2020-07-28 6:27 ` Liu Yi L
2020-08-16 12:01 ` Auger Eric
2020-08-16 12:01 ` Auger Eric
2020-08-17 7:05 ` Liu, Yi L
2020-08-17 7:05 ` Liu, Yi L
2020-08-17 7:42 ` Auger Eric
2020-08-17 7:42 ` Auger Eric
2020-08-17 7:45 ` Liu, Yi L
2020-08-17 7:45 ` 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=20200817212152.2820eedd@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=eric.auger@redhat.com \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=jun.j.tian@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefanha@gmail.com \
--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 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.