From: "Liu, Yi L" <yi.l.liu@intel.com> To: Auger Eric <eric.auger@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "peterx@redhat.com" <peterx@redhat.com> Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>, "mst@redhat.com" <mst@redhat.com>, "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>, "Tian, Kevin" <kevin.tian@intel.com>, "Tian, Jun J" <jun.j.tian@intel.com>, "Sun, Yi Y" <yi.y.sun@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Wu, Hao" <hao.wu@intel.com>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, Jacob Pan <jacob.jun.pan@linux.intel.com>, Yi Sun <yi.y.sun@linux.intel.com>, "Richard Henderson" <rth@twiddle.net>, Eduardo Habkost <ehabkost@redhat.com> Subject: RE: [PATCH v2 07/22] intel_iommu: add set/unset_iommu_context callback Date: Tue, 31 Mar 2020 12:25:59 +0000 [thread overview] Message-ID: <A2975661238FB949B60364EF0F2C25743A21AF24@SHSMSX104.ccr.corp.intel.com> (raw) In-Reply-To: <a444318b-32c7-d43c-112a-d35a870b162d@redhat.com> Hi Eric, > From: Auger Eric < eric.auger@redhat.com> > Sent: Tuesday, March 31, 2020 4:24 AM > To: Liu, Yi L <yi.l.liu@intel.com>; qemu-devel@nongnu.org; > Subject: Re: [PATCH v2 07/22] intel_iommu: add set/unset_iommu_context callback > > Yi, > > On 3/30/20 6:24 AM, Liu Yi L wrote: > > This patch adds set/unset_iommu_context() impelementation in Intel > This patch implements the set/unset_iommu_context() ops for Intel vIOMMU. > > vIOMMU. For Intel platform, pass-through modules (e.g. VFIO) could > > set HostIOMMUContext to Intel vIOMMU emulator. > > > > Cc: Kevin Tian <kevin.tian@intel.com> > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Cc: Peter Xu <peterx@redhat.com> > > Cc: Yi Sun <yi.y.sun@linux.intel.com> > > Cc: Paolo Bonzini <pbonzini@redhat.com> > > Cc: Richard Henderson <rth@twiddle.net> > > Cc: Eduardo Habkost <ehabkost@redhat.com> > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > > --- > > hw/i386/intel_iommu.c | 71 > ++++++++++++++++++++++++++++++++++++++++--- > > include/hw/i386/intel_iommu.h | 21 ++++++++++--- > > 2 files changed, 83 insertions(+), 9 deletions(-) > > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > > index 4b22910..fd349c6 100644 > > --- a/hw/i386/intel_iommu.c > > +++ b/hw/i386/intel_iommu.c > > @@ -3354,23 +3354,33 @@ static const MemoryRegionOps vtd_mem_ir_ops = { > > }, > > }; > > > > -VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn) > > +/** > > + * Fetch a VTDBus instance for given PCIBus. If no existing instance, > > + * allocate one. > > + */ > > +static VTDBus *vtd_find_add_bus(IntelIOMMUState *s, PCIBus *bus) > > { > > uintptr_t key = (uintptr_t)bus; > > VTDBus *vtd_bus = g_hash_table_lookup(s->vtd_as_by_busptr, &key); > > - VTDAddressSpace *vtd_dev_as; > > - char name[128]; > > > > if (!vtd_bus) { > > uintptr_t *new_key = g_malloc(sizeof(*new_key)); > > *new_key = (uintptr_t)bus; > > /* No corresponding free() */ > > - vtd_bus = g_malloc0(sizeof(VTDBus) + sizeof(VTDAddressSpace *) * \ > > - PCI_DEVFN_MAX); > > + vtd_bus = g_malloc0(sizeof(VTDBus)); > > vtd_bus->bus = bus; > > g_hash_table_insert(s->vtd_as_by_busptr, new_key, vtd_bus); > > } > > + return vtd_bus; > > +} > > > > +VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn) > > +{ > > + VTDBus *vtd_bus; > > + VTDAddressSpace *vtd_dev_as; > > + char name[128]; > > + > > + vtd_bus = vtd_find_add_bus(s, bus); > > vtd_dev_as = vtd_bus->dev_as[devfn]; > > > > if (!vtd_dev_as) { > > @@ -3436,6 +3446,55 @@ VTDAddressSpace > *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn) > > return vtd_dev_as; > > } > > > > +static int vtd_dev_set_iommu_context(PCIBus *bus, void *opaque, > > + int devfn, > > + HostIOMMUContext *iommu_ctx) > > +{ > > + IntelIOMMUState *s = opaque; > > + VTDBus *vtd_bus; > > + VTDHostIOMMUContext *vtd_dev_icx; > > + > > + assert(0 <= devfn && devfn < PCI_DEVFN_MAX); > > + > > + vtd_bus = vtd_find_add_bus(s, bus); > > + > > + vtd_iommu_lock(s); > > + > > + vtd_dev_icx = vtd_bus->dev_icx[devfn]; > > + > > + assert(!vtd_dev_icx); > > + > > + vtd_bus->dev_icx[devfn] = vtd_dev_icx = > > + g_malloc0(sizeof(VTDHostIOMMUContext)); > > + vtd_dev_icx->vtd_bus = vtd_bus; > > + vtd_dev_icx->devfn = (uint8_t)devfn; > > + vtd_dev_icx->iommu_state = s; > > + vtd_dev_icx->iommu_ctx = iommu_ctx; > > + > > + vtd_iommu_unlock(s); > > + > > + return 0; > > +} > > + > > +static void vtd_dev_unset_iommu_context(PCIBus *bus, void *opaque, int devfn) > > +{ > > + IntelIOMMUState *s = opaque; > > + VTDBus *vtd_bus; > > + VTDHostIOMMUContext *vtd_dev_icx; > > + > > + assert(0 <= devfn && devfn < PCI_DEVFN_MAX); > > + > > + vtd_bus = vtd_find_add_bus(s, bus); > > + > > + vtd_iommu_lock(s); > > + > > + vtd_dev_icx = vtd_bus->dev_icx[devfn]; > > + g_free(vtd_dev_icx); > > + vtd_bus->dev_icx[devfn] = NULL; > > + > > + vtd_iommu_unlock(s); > > +} > > + > > static uint64_t get_naturally_aligned_size(uint64_t start, > > uint64_t size, int gaw) > > { > > @@ -3731,6 +3790,8 @@ static AddressSpace *vtd_host_dma_iommu(PCIBus > *bus, void *opaque, int devfn) > > > > static PCIIOMMUOps vtd_iommu_ops = { > > .get_address_space = vtd_host_dma_iommu, > > + .set_iommu_context = vtd_dev_set_iommu_context, > > + .unset_iommu_context = vtd_dev_unset_iommu_context, > > }; > > > > static bool vtd_decide_config(IntelIOMMUState *s, Error **errp) > > diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h > > index 3870052..b5fefb9 100644 > > --- a/include/hw/i386/intel_iommu.h > > +++ b/include/hw/i386/intel_iommu.h > > @@ -64,6 +64,7 @@ typedef union VTD_IR_TableEntry VTD_IR_TableEntry; > > typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress; > > typedef struct VTDPASIDDirEntry VTDPASIDDirEntry; > > typedef struct VTDPASIDEntry VTDPASIDEntry; > > +typedef struct VTDHostIOMMUContext VTDHostIOMMUContext; > > > > /* Context-Entry */ > > struct VTDContextEntry { > > @@ -112,10 +113,20 @@ struct VTDAddressSpace { > > IOVATree *iova_tree; /* Traces mapped IOVA ranges */ > > }; > > > > +struct VTDHostIOMMUContext { > > > > + VTDBus *vtd_bus; > > + uint8_t devfn; > > + HostIOMMUContext *iommu_ctx; > I don't get why we don't have standard QOM inheritance instead of this > handle? > VTDHostContext parent_obj; > > like IOMMUMemoryRegion <- MemoryRegion <- Object Here it is not inherit the object. It's just cache the HostIOMMUContext pointer in vIOMMU. Just like AddressSpace, it has a MemoryRegion pointer. Here is the same, VTDHostIOMMUContext is just a wrapper to better manage it in vVT-d. It's not inheriting. > > + IntelIOMMUState *iommu_state; > > +}; > > + > > struct VTDBus { > > - PCIBus* bus; /* A reference to the bus to provide translation for > */ > > + /* A reference to the bus to provide translation for */ > > + PCIBus *bus; > > /* A table of VTDAddressSpace objects indexed by devfn */ > > - VTDAddressSpace *dev_as[]; > > + VTDAddressSpace *dev_as[PCI_DEVFN_MAX]; > > + /* A table of VTDHostIOMMUContext objects indexed by devfn */ > > + VTDHostIOMMUContext *dev_icx[PCI_DEVFN_MAX]; > At this point of the review, it is unclear to me why the context is > associated to a device. HostIOMMUContext can be per-device or not. It depends on how vIOMMU manage it. For vVT-d, it's per device as the container is per-device. > Up to now you have not explained it should. If > so why isn't it part of VTDAddressSpace? Ah, I did have considered it. But I chose to use a separate one as context is not really tied with an addresspace. It's better to mange it with a separate structure. Regards, Yi Liu
WARNING: multiple messages have this Message-ID (diff)
From: "Liu, Yi L" <yi.l.liu@intel.com> To: Auger Eric <eric.auger@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "peterx@redhat.com" <peterx@redhat.com> Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "Tian, Kevin" <kevin.tian@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>, Yi Sun <yi.y.sun@linux.intel.com>, Eduardo Habkost <ehabkost@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "mst@redhat.com" <mst@redhat.com>, "Tian, Jun J" <jun.j.tian@intel.com>, "Sun, Yi Y" <yi.y.sun@intel.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>, "Wu, Hao" <hao.wu@intel.com>, Richard Henderson <rth@twiddle.net>, "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au> Subject: RE: [PATCH v2 07/22] intel_iommu: add set/unset_iommu_context callback Date: Tue, 31 Mar 2020 12:25:59 +0000 [thread overview] Message-ID: <A2975661238FB949B60364EF0F2C25743A21AF24@SHSMSX104.ccr.corp.intel.com> (raw) In-Reply-To: <a444318b-32c7-d43c-112a-d35a870b162d@redhat.com> Hi Eric, > From: Auger Eric < eric.auger@redhat.com> > Sent: Tuesday, March 31, 2020 4:24 AM > To: Liu, Yi L <yi.l.liu@intel.com>; qemu-devel@nongnu.org; > Subject: Re: [PATCH v2 07/22] intel_iommu: add set/unset_iommu_context callback > > Yi, > > On 3/30/20 6:24 AM, Liu Yi L wrote: > > This patch adds set/unset_iommu_context() impelementation in Intel > This patch implements the set/unset_iommu_context() ops for Intel vIOMMU. > > vIOMMU. For Intel platform, pass-through modules (e.g. VFIO) could > > set HostIOMMUContext to Intel vIOMMU emulator. > > > > Cc: Kevin Tian <kevin.tian@intel.com> > > Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> > > Cc: Peter Xu <peterx@redhat.com> > > Cc: Yi Sun <yi.y.sun@linux.intel.com> > > Cc: Paolo Bonzini <pbonzini@redhat.com> > > Cc: Richard Henderson <rth@twiddle.net> > > Cc: Eduardo Habkost <ehabkost@redhat.com> > > Signed-off-by: Liu Yi L <yi.l.liu@intel.com> > > --- > > hw/i386/intel_iommu.c | 71 > ++++++++++++++++++++++++++++++++++++++++--- > > include/hw/i386/intel_iommu.h | 21 ++++++++++--- > > 2 files changed, 83 insertions(+), 9 deletions(-) > > > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c > > index 4b22910..fd349c6 100644 > > --- a/hw/i386/intel_iommu.c > > +++ b/hw/i386/intel_iommu.c > > @@ -3354,23 +3354,33 @@ static const MemoryRegionOps vtd_mem_ir_ops = { > > }, > > }; > > > > -VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn) > > +/** > > + * Fetch a VTDBus instance for given PCIBus. If no existing instance, > > + * allocate one. > > + */ > > +static VTDBus *vtd_find_add_bus(IntelIOMMUState *s, PCIBus *bus) > > { > > uintptr_t key = (uintptr_t)bus; > > VTDBus *vtd_bus = g_hash_table_lookup(s->vtd_as_by_busptr, &key); > > - VTDAddressSpace *vtd_dev_as; > > - char name[128]; > > > > if (!vtd_bus) { > > uintptr_t *new_key = g_malloc(sizeof(*new_key)); > > *new_key = (uintptr_t)bus; > > /* No corresponding free() */ > > - vtd_bus = g_malloc0(sizeof(VTDBus) + sizeof(VTDAddressSpace *) * \ > > - PCI_DEVFN_MAX); > > + vtd_bus = g_malloc0(sizeof(VTDBus)); > > vtd_bus->bus = bus; > > g_hash_table_insert(s->vtd_as_by_busptr, new_key, vtd_bus); > > } > > + return vtd_bus; > > +} > > > > +VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn) > > +{ > > + VTDBus *vtd_bus; > > + VTDAddressSpace *vtd_dev_as; > > + char name[128]; > > + > > + vtd_bus = vtd_find_add_bus(s, bus); > > vtd_dev_as = vtd_bus->dev_as[devfn]; > > > > if (!vtd_dev_as) { > > @@ -3436,6 +3446,55 @@ VTDAddressSpace > *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn) > > return vtd_dev_as; > > } > > > > +static int vtd_dev_set_iommu_context(PCIBus *bus, void *opaque, > > + int devfn, > > + HostIOMMUContext *iommu_ctx) > > +{ > > + IntelIOMMUState *s = opaque; > > + VTDBus *vtd_bus; > > + VTDHostIOMMUContext *vtd_dev_icx; > > + > > + assert(0 <= devfn && devfn < PCI_DEVFN_MAX); > > + > > + vtd_bus = vtd_find_add_bus(s, bus); > > + > > + vtd_iommu_lock(s); > > + > > + vtd_dev_icx = vtd_bus->dev_icx[devfn]; > > + > > + assert(!vtd_dev_icx); > > + > > + vtd_bus->dev_icx[devfn] = vtd_dev_icx = > > + g_malloc0(sizeof(VTDHostIOMMUContext)); > > + vtd_dev_icx->vtd_bus = vtd_bus; > > + vtd_dev_icx->devfn = (uint8_t)devfn; > > + vtd_dev_icx->iommu_state = s; > > + vtd_dev_icx->iommu_ctx = iommu_ctx; > > + > > + vtd_iommu_unlock(s); > > + > > + return 0; > > +} > > + > > +static void vtd_dev_unset_iommu_context(PCIBus *bus, void *opaque, int devfn) > > +{ > > + IntelIOMMUState *s = opaque; > > + VTDBus *vtd_bus; > > + VTDHostIOMMUContext *vtd_dev_icx; > > + > > + assert(0 <= devfn && devfn < PCI_DEVFN_MAX); > > + > > + vtd_bus = vtd_find_add_bus(s, bus); > > + > > + vtd_iommu_lock(s); > > + > > + vtd_dev_icx = vtd_bus->dev_icx[devfn]; > > + g_free(vtd_dev_icx); > > + vtd_bus->dev_icx[devfn] = NULL; > > + > > + vtd_iommu_unlock(s); > > +} > > + > > static uint64_t get_naturally_aligned_size(uint64_t start, > > uint64_t size, int gaw) > > { > > @@ -3731,6 +3790,8 @@ static AddressSpace *vtd_host_dma_iommu(PCIBus > *bus, void *opaque, int devfn) > > > > static PCIIOMMUOps vtd_iommu_ops = { > > .get_address_space = vtd_host_dma_iommu, > > + .set_iommu_context = vtd_dev_set_iommu_context, > > + .unset_iommu_context = vtd_dev_unset_iommu_context, > > }; > > > > static bool vtd_decide_config(IntelIOMMUState *s, Error **errp) > > diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h > > index 3870052..b5fefb9 100644 > > --- a/include/hw/i386/intel_iommu.h > > +++ b/include/hw/i386/intel_iommu.h > > @@ -64,6 +64,7 @@ typedef union VTD_IR_TableEntry VTD_IR_TableEntry; > > typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress; > > typedef struct VTDPASIDDirEntry VTDPASIDDirEntry; > > typedef struct VTDPASIDEntry VTDPASIDEntry; > > +typedef struct VTDHostIOMMUContext VTDHostIOMMUContext; > > > > /* Context-Entry */ > > struct VTDContextEntry { > > @@ -112,10 +113,20 @@ struct VTDAddressSpace { > > IOVATree *iova_tree; /* Traces mapped IOVA ranges */ > > }; > > > > +struct VTDHostIOMMUContext { > > > > + VTDBus *vtd_bus; > > + uint8_t devfn; > > + HostIOMMUContext *iommu_ctx; > I don't get why we don't have standard QOM inheritance instead of this > handle? > VTDHostContext parent_obj; > > like IOMMUMemoryRegion <- MemoryRegion <- Object Here it is not inherit the object. It's just cache the HostIOMMUContext pointer in vIOMMU. Just like AddressSpace, it has a MemoryRegion pointer. Here is the same, VTDHostIOMMUContext is just a wrapper to better manage it in vVT-d. It's not inheriting. > > + IntelIOMMUState *iommu_state; > > +}; > > + > > struct VTDBus { > > - PCIBus* bus; /* A reference to the bus to provide translation for > */ > > + /* A reference to the bus to provide translation for */ > > + PCIBus *bus; > > /* A table of VTDAddressSpace objects indexed by devfn */ > > - VTDAddressSpace *dev_as[]; > > + VTDAddressSpace *dev_as[PCI_DEVFN_MAX]; > > + /* A table of VTDHostIOMMUContext objects indexed by devfn */ > > + VTDHostIOMMUContext *dev_icx[PCI_DEVFN_MAX]; > At this point of the review, it is unclear to me why the context is > associated to a device. HostIOMMUContext can be per-device or not. It depends on how vIOMMU manage it. For vVT-d, it's per device as the container is per-device. > Up to now you have not explained it should. If > so why isn't it part of VTDAddressSpace? Ah, I did have considered it. But I chose to use a separate one as context is not really tied with an addresspace. It's better to mange it with a separate structure. Regards, Yi Liu
next prev parent reply other threads:[~2020-03-31 12:26 UTC|newest] Thread overview: 160+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-30 4:24 [PATCH v2 00/22] intel_iommu: expose Shared Virtual Addressing to VMs Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 01/22] scripts/update-linux-headers: Import iommu.h Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 02/22] header file update VFIO/IOMMU vSVA APIs Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 03/22] vfio: check VFIO_TYPE1_NESTING_IOMMU support Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 9:36 ` Auger Eric 2020-03-30 9:36 ` Auger Eric 2020-03-31 6:08 ` Liu, Yi L 2020-03-31 6:08 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 04/22] hw/iommu: introduce HostIOMMUContext Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 17:22 ` Auger Eric 2020-03-30 17:22 ` Auger Eric 2020-03-31 4:10 ` Liu, Yi L 2020-03-31 4:10 ` Liu, Yi L 2020-03-31 7:47 ` Auger Eric 2020-03-31 7:47 ` Auger Eric 2020-03-31 12:43 ` Liu, Yi L 2020-03-31 12:43 ` Liu, Yi L 2020-04-06 8:04 ` Liu, Yi L 2020-04-06 8:04 ` Liu, Yi L 2020-04-06 10:30 ` Auger Eric 2020-04-06 10:30 ` Auger Eric 2020-03-30 4:24 ` [PATCH v2 05/22] hw/pci: modify pci_setup_iommu() to set PCIIOMMUOps Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 11:02 ` Auger Eric 2020-03-30 11:02 ` Auger Eric 2020-04-02 8:52 ` Liu, Yi L 2020-04-02 8:52 ` Liu, Yi L 2020-04-02 12:41 ` Auger Eric 2020-04-02 12:41 ` Auger Eric 2020-04-02 13:37 ` Liu, Yi L 2020-04-02 13:37 ` Liu, Yi L 2020-04-02 13:49 ` Auger Eric 2020-04-02 13:49 ` Auger Eric 2020-04-06 6:27 ` Liu, Yi L 2020-04-06 6:27 ` Liu, Yi L 2020-04-06 10:04 ` Auger Eric 2020-04-06 10:04 ` Auger Eric 2020-03-30 4:24 ` [PATCH v2 06/22] hw/pci: introduce pci_device_set/unset_iommu_context() Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 17:30 ` Auger Eric 2020-03-30 17:30 ` Auger Eric 2020-03-31 12:14 ` Liu, Yi L 2020-03-31 12:14 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 07/22] intel_iommu: add set/unset_iommu_context callback Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 20:23 ` Auger Eric 2020-03-30 20:23 ` Auger Eric 2020-03-31 12:25 ` Liu, Yi L [this message] 2020-03-31 12:25 ` Liu, Yi L 2020-03-31 12:57 ` Auger Eric 2020-03-31 12:57 ` Auger Eric 2020-03-30 4:24 ` [PATCH v2 08/22] vfio/common: provide PASID alloc/free hooks Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-31 10:47 ` Auger Eric 2020-03-31 10:47 ` Auger Eric 2020-03-31 10:59 ` Liu, Yi L 2020-03-31 10:59 ` Liu, Yi L 2020-03-31 11:15 ` Auger Eric 2020-03-31 11:15 ` Auger Eric 2020-03-31 12:54 ` Liu, Yi L 2020-03-31 12:54 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 09/22] vfio/common: init HostIOMMUContext per-container Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-04-01 7:50 ` Auger Eric 2020-04-01 7:50 ` Auger Eric 2020-04-06 7:12 ` Liu, Yi L 2020-04-06 7:12 ` Liu, Yi L 2020-04-06 10:20 ` Auger Eric 2020-04-06 10:20 ` Auger Eric 2020-04-07 11:59 ` Liu, Yi L 2020-04-07 11:59 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 10/22] vfio/pci: set host iommu context to vIOMMU Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-31 14:30 ` Auger Eric 2020-03-31 14:30 ` Auger Eric 2020-04-01 3:20 ` Liu, Yi L 2020-04-01 3:20 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 11/22] intel_iommu: add virtual command capability support Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 12/22] intel_iommu: process PASID cache invalidation Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 13/22] intel_iommu: add PASID cache management infrastructure Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-04-02 0:02 ` Peter Xu 2020-04-02 0:02 ` Peter Xu 2020-04-02 6:46 ` Liu, Yi L 2020-04-02 6:46 ` Liu, Yi L 2020-04-02 13:44 ` Peter Xu 2020-04-02 13:44 ` Peter Xu 2020-04-03 15:05 ` Liu, Yi L 2020-04-03 15:05 ` Liu, Yi L 2020-04-03 16:19 ` Peter Xu 2020-04-03 16:19 ` Peter Xu 2020-04-04 11:39 ` Liu, Yi L 2020-04-04 11:39 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 14/22] vfio: add bind stage-1 page table support Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 15/22] intel_iommu: bind/unbind guest page table to host Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-04-02 18:09 ` Peter Xu 2020-04-02 18:09 ` Peter Xu 2020-04-03 14:29 ` Liu, Yi L 2020-04-03 14:29 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 16/22] intel_iommu: replay pasid binds after context cache invalidation Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-04-03 14:45 ` Peter Xu 2020-04-03 14:45 ` Peter Xu 2020-04-03 15:21 ` Liu, Yi L 2020-04-03 15:21 ` Liu, Yi L 2020-04-03 16:11 ` Peter Xu 2020-04-03 16:11 ` Peter Xu 2020-04-04 12:00 ` Liu, Yi L 2020-04-04 12:00 ` Liu, Yi L 2020-04-06 19:48 ` Peter Xu 2020-04-06 19:48 ` Peter Xu 2020-03-30 4:24 ` [PATCH v2 17/22] intel_iommu: do not pass down pasid bind for PASID #0 Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 18/22] vfio: add support for flush iommu stage-1 cache Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:24 ` [PATCH v2 19/22] intel_iommu: process PASID-based iotlb invalidation Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-04-03 14:47 ` Peter Xu 2020-04-03 14:47 ` Peter Xu 2020-04-03 15:21 ` Liu, Yi L 2020-04-03 15:21 ` Liu, Yi L 2020-03-30 4:24 ` [PATCH v2 20/22] intel_iommu: propagate PASID-based iotlb invalidation to host Liu Yi L 2020-03-30 4:24 ` Liu Yi L 2020-03-30 4:25 ` [PATCH v2 21/22] intel_iommu: process PASID-based Device-TLB invalidation Liu Yi L 2020-03-30 4:25 ` Liu Yi L 2020-03-30 4:25 ` [PATCH v2 22/22] intel_iommu: modify x-scalable-mode to be string option Liu Yi L 2020-03-30 4:25 ` Liu Yi L 2020-04-03 14:49 ` Peter Xu 2020-04-03 14:49 ` Peter Xu 2020-04-03 15:22 ` Liu, Yi L 2020-04-03 15:22 ` Liu, Yi L 2020-03-30 5:40 ` [PATCH v2 00/22] intel_iommu: expose Shared Virtual Addressing to VMs no-reply 2020-03-30 5:40 ` no-reply 2020-03-30 10:36 ` Auger Eric 2020-03-30 10:36 ` Auger Eric 2020-03-30 14:46 ` Peter Xu 2020-03-30 14:46 ` Peter Xu 2020-03-31 6:53 ` Liu, Yi L 2020-03-31 6:53 ` Liu, Yi L 2020-04-02 8:33 ` Jason Wang 2020-04-02 8:33 ` Jason Wang 2020-04-02 13:46 ` Peter Xu 2020-04-02 13:46 ` Peter Xu 2020-04-03 1:38 ` Jason Wang 2020-04-03 1:38 ` Jason Wang 2020-04-03 14:20 ` Liu, Yi L 2020-04-03 14:20 ` Liu, Yi L 2020-04-02 18:12 ` Peter Xu 2020-04-02 18:12 ` Peter Xu 2020-04-03 14:32 ` Liu, Yi L 2020-04-03 14:32 ` 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=A2975661238FB949B60364EF0F2C25743A21AF24@SHSMSX104.ccr.corp.intel.com \ --to=yi.l.liu@intel.com \ --cc=alex.williamson@redhat.com \ --cc=david@gibson.dropbear.id.au \ --cc=ehabkost@redhat.com \ --cc=eric.auger@redhat.com \ --cc=hao.wu@intel.com \ --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=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=peterx@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=rth@twiddle.net \ --cc=yi.y.sun@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: 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.