Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on vfio/next]
[also build test ERROR on v5.6-rc6 next-20200320]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option
On 2020/3/21 0:20, Jacob Pan wrote:
On Fri, 20 Mar 2020 21:45:26 +0800
Lu Baolu wrote:
On 2020/3/20 12:32, Jacob Pan wrote:
IOTLB flush already included in the PASID tear down process. There
is no need to flush again.
It seems that intel_pasid_tear_down_entry() doesn't flush the pasid
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to enable SVA virtualization, i.e. enable use of SVA
within a
Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
With PASID granular translation type set to 0x11b, translation
result from the first level(FL) also subject to a second level(SL)
page table translation. This mode is used for SVA virtualization,
where FL performs guest virtual to guest
When supporting guest SVA with emulated IOMMU, the guest PASID
table is shadowed in VMM. Updates to guest vIOMMU PASID table
will result in PASID cache flush which will be passed down to
the host as bind guest PASID calls.
For the SL page tables, it will be harvested from device's
default domain
When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
IOTLB invalidation may be passed down from outside IOMMU subsystems.
This patch adds invalidation functions that can be used for additional
translation cache types.
Signed-off-by: Jacob Pan
---
v9 -> v10:
Fix off by 1 in
From: Lu Baolu
Enabling IOMMU in a guest requires communication with the host
driver for certain aspects. Use of PASID ID to enable Shared Virtual
Addressing (SVA) requires managing PASID's in the host. VT-d 3.0 spec
provides a Virtual Command Register (VCMD) to facilitate this.
Writes to this
When Shared Virtual Address (SVA) is enabled for a guest OS via
vIOMMU, we need to provide invalidation support at IOMMU API and driver
level. This patch adds Intel VT-d specific function to implement
iommu passdown invalidate API for shared virtual address.
The use case is for supporting caching
When VT-d driver runs in the guest, PASID allocation must be
performed via virtual command interface. This patch registers a
custom IOASID allocator which takes precedence over the default
XArray based allocator. The resulting IOASID allocation will always
come from the host. This ensures that
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-pasid.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
index 22b30f10b396..191508c7c03e 100644
--- a/drivers/iommu/intel-pasid.c
+++
Move domain helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
---
drivers/iommu/intel-iommu.c | 6 --
include/linux/intel-iommu.h | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-pasid.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
index 191508c7c03e..9bdb7ee228b6 100644
--- a/drivers/iommu/intel-pasid.c
+++
Memory type related flags can be grouped together for one simple check.
---
v9 renamed from EMT to MTS since these are memory type support flags.
---
Signed-off-by: Jacob Pan
---
include/uapi/linux/iommu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Virtual command registers are used in the guest only, to prevent
vmexit cost, we cache the capability and store it during initialization.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Reviewed-by: Lu Baolu
---
v7 Reviewed by Eric & Baolu
---
---
drivers/iommu/dmar.c| 1 +
Hi Eric,
I love your patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on linus/master v5.6-rc6 next-20200320]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base
On Wed, 12 Feb 2020 13:43:43 +0100
Auger Eric wrote:
> Hi Jacob,
>
> On 1/29/20 7:01 AM, Jacob Pan wrote:
> > Memory type related guest PASID bind data can be grouped together
> > for one simple check.
> Those are flags related to memory type.
right, will rephrase.
> > Link:
> >
Hi John,
On 2020-03-20 16:20, John Garry wrote:
I've run a bunch of netperf instances on multiple cores and
collecting
SMMU usage (on TaiShan 2280). I'm getting the following ratio pretty
consistently.
- 6.07% arm_smmu_iotlb_sync
- 5.74% arm_smmu_tlb_inv_range
5.09%
The VFIO API was enhanced to support nested stage control: a bunch of
new iotcls, one DMA FAULT region and an associated specific IRQ.
Let's document the process to follow to set up nested mode.
Signed-off-by: Eric Auger
---
v8 -> v9:
- new names for SET_MSI_BINDING and SET_PASID_TABLE
- new
I've run a bunch of netperf instances on multiple cores and collecting
SMMU usage (on TaiShan 2280). I'm getting the following ratio pretty
consistently.
- 6.07% arm_smmu_iotlb_sync
- 5.74% arm_smmu_tlb_inv_range
5.09% arm_smmu_cmdq_issue_cmdlist
0.28% __pi_memset
Register the VFIO_IRQ_TYPE_NESTED/VFIO_IRQ_SUBTYPE_DMA_FAULT
IRQ that allows to signal a nested mode DMA fault.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c
Implement IRQ capability chain infrastructure. All interrupt
indexes beyond VFIO_PCI_NUM_IRQS are handled as extended
interrupts. They are registered with a specific type/subtype
and supported flags.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 100
From: Tina Zhang
Caps the number of irqs with fixed indexes and uses capability chains
to chain device specific irqs.
Signed-off-by: Tina Zhang
Signed-off-by: Eric Auger
[Eric: Put cap_offset at the end of the vfio_irq_info struct,
remove GFX IRQ at the moment and remove any reference to this
Add a new IRQ type/subtype to get notification on nested
stage DMA faults.
Signed-off-by: Eric Auger
---
include/uapi/linux/vfio.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index f0fd26d058c9..73a6bf072b10 100644
---
This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim
to (un)register the guest MSI binding to the host. This latter
then can use those stage 1 bindings to build a nested stage
binding targeting the physical MSIs.
Signed-off-by: Eric Auger
---
v8 -> v9:
- merge
The DMA FAULT region contains the fault ring buffer.
There is benefit to let the userspace mmap this area.
Expose this mmappable area through a sparse mmap entry
and implement the mmap operation.
Signed-off-by: Eric Auger
---
v8 -> v9:
- remove unused index local variable in
From: "Liu, Yi L"
This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
which aims to pass the virtual iommu guest configuration
to the host. This latter takes the form of the so-called
PASID table.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi L
Signed-off-by: Eric Auger
---
v8 -> v9:
-
Register an IOMMU fault handler which records faults in
the DMA FAULT region ring buffer. In a subsequent patch, we
will add the signaling of a specific eventfd to allow the
userspace to be notified whenever a new fault as shown up.
Signed-off-by: Eric Auger
---
v8 -> v9:
- handler now takes
From: "Liu, Yi L"
When the guest "owns" the stage 1 translation structures, the host
IOMMU driver has no knowledge of caching structure updates unless
the guest invalidation requests are trapped and passed down to the
host.
This patch adds the VFIO_IOMMU_CACHE_INVALIDATE ioctl with aims
at
This series brings the VFIO part of HW nested paging support
in the SMMUv3.
This is a rebase on top of Will's arm-smmu-updates branch
(git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
tags/arm-smmu-updates)
This is basically a resend of v9 as patches still applied.
This work has
Add a new specific DMA_FAULT region aiming to exposed nested mode
translation faults.
The region has a ring buffer that contains the actual fault
records plus a header allowing to handle it (tail/head indices,
max capacity, entry size). At the moment the region is dimensionned
for 512 fault
On Fri, 20 Mar 2020 21:45:26 +0800
Lu Baolu wrote:
> On 2020/3/20 12:32, Jacob Pan wrote:
> > IOTLB flush already included in the PASID tear down process. There
> > is no need to flush again.
>
> It seems that intel_pasid_tear_down_entry() doesn't flush the pasid
> based device TLB?
>
I saw
When a stage 1 related fault event is read from the event queue,
let's propagate it to potential external fault listeners, ie. users
who registered a fault handler.
Signed-off-by: Eric Auger
---
v8 -> v9:
- adapt to the removal of IOMMU_FAULT_UNRECOV_PERM_VALID:
only look at
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest MSI doorbell (gDB). The Host allocates
another
Nested mode currently is not compatible with HW MSI reserved regions.
Indeed MSI transactions targeting this MSI doorbells bypass the SMMU.
Let's check nested mode is not attempted in such configuration.
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu-v3.c | 23 +--
1
The bind/unbind_guest_msi() callbacks check the domain
is NESTED and redirect to the dma-iommu implementation.
Signed-off-by: Eric Auger
---
v6 -> v7:
- remove device handle argument
---
drivers/iommu/arm-smmu-v3.c | 43 +
1 file changed, 43 insertions(+)
In nested mode we enforce the rule that all devices belonging
to the same iommu_domain share the same msi_domain.
Indeed if there were several physical MSI doorbells being used
within a single iommu_domain, it becomes really difficult to
resolve the nested stage mapping translating into the
Implement domain-selective and page-selective IOTLB invalidations.
Signed-off-by: Eric Auger
---
v7 -> v8:
- ASID based invalidation using iommu_inv_pasid_info
- check ARCHID/PASID flags in addr based invalidation
- use __arm_smmu_tlb_inv_context and __arm_smmu_tlb_inv_range_nosync
v6 -> v7
-
With nested stage support, soon we will need to invalidate
S1 contexts and ranges tagged with an unmanaged asid, this
latter being managed by the guest. So let's introduce 2 helpers
that allow to invalidate with externally managed ASIDs
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu-v3.c
On attach_pasid_table() we program STE S1 related info set
by the guest into the actual physical STEs. At minimum
we need to program the context descriptor GPA and compute
whether the stage1 is translated/bypassed or aborted.
Signed-off-by: Eric Auger
---
v7 -> v8:
- remove smmu->features
From: Jacob Pan
In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on the guest,
the physical IOMMU must be programmed to be consistent with
the guest mappings. If the physical IOMMU supports two
translation stages it makes sense to program guest
When nested stage translation is setup, both s1_cfg and
s2_cfg are allocated.
We introduce a new smmu domain abort field that will be set
upon guest stage1 configuration passing.
arm_smmu_write_strtab_ent() is modified to write both stage
fields in the STE and deal with the abort field.
In
In preparation for the introduction of nested stages
let's turn s1_cfg and s2_cfg fields into pointers which are
dynamically allocated depending on the smmu_domain stage.
In nested mode, both stages will coexist and s1_cfg will
be allocated when the guest configuration gets passed.
On Fri, Mar 20, 2020 at 03:35:20PM +, Will Deacon wrote:
> Hi Joerg,
>
> Please pull these Arm SMMU updates for 5.7. The summary is in the tag (which
> you may need to re-fetch if you've got my tree added as a remote).
>
> Cheers,
>
> Will
>
> --->8
>
> The following changes since commit
On ARM, MSI are translated by the SMMU. An IOVA is allocated
for each MSI doorbell. If both the host and the guest are exposed
with SMMUs, we end up with 2 different IOVAs allocated by each.
guest allocates an IOVA (gIOVA) to map onto the guest MSI
doorbell (gDB). The Host allocates another IOVA
From: Jean-Philippe Brucker
When handling faults from the event or PRI queue, we need to find the
struct device associated to a SID. Add a rb_tree to keep track of SIDs.
Signed-off-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 112
This is a rebase on top of Will's arm-smmu-updates branch
(git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
tags/arm-smmu-updates)
This work has been stalled since Plumber 2019. Since then
some users expressed interest in that work and tested v9:
-
Hi Joerg,
Please pull these Arm SMMU updates for 5.7. The summary is in the tag (which
you may need to re-fetch if you've got my tree added as a remote).
Cheers,
Will
--->8
The following changes since commit f8788d86ab28f61f7b46eb6be375f8a726783636:
Linux 5.6-rc3 (2020-02-23 16:17:42
On Fri, Mar 20, 2020 at 03:16:39PM +0100, Christoph Hellwig wrote:
> Several IOMMU drivers have a bypass mode where they can use a direct
> mapping if the devices DMA mask is large enough. Add generic support
> to the core dma-mapping code to do that to switch those drivers to
> a common
Hi all,
I've recently beeing chatting with Lu about using dma-iommu and
per-device DMA ops in the intel IOMMU driver, and one missing feature
in dma-iommu is a bypass mode where the direct mapping is used even
when an iommu is attached to improve performance. The powerpc
code already has a
Use the DMA API bypass mechanism for direct window mappings. This uses
common code and speed up the direct mapping case by avoiding indirect
calls just when not using dma ops at all. It also fixes a problem where
the sync_* methods were using the bypass check for DMA allocations, but
those are
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Signed-off-by: Christoph Hellwig
---
include/linux/device.h | 6
On 2020/3/20 12:32, Jacob Pan wrote:
IOASID code is needed by VT-d scalable mode for PASID allocation.
Add explicit dependency such that IOASID is built-in whenever Intel
IOMMU is enabled.
Otherwise, aux domain code will fail when IOMMU is built-in and IOASID
is compiled as a module.
On 2020/3/20 12:32, Jacob Pan wrote:
Move canonical address check before mmget_not_zero() to avoid mm
reference leak.
Fixes: 9d8c3af31607 ("iommu/vt-d: IOMMU Page Request needs to check if
address is canonical.")
Signed-off-by: Jacob Pan
Acked-by: Lu Baolu
Best regards,
baolu
---
On 2020/3/20 12:32, Jacob Pan wrote:
IOTLB flush already included in the PASID tear down process. There
is no need to flush again.
It seems that intel_pasid_tear_down_entry() doesn't flush the pasid
based device TLB?
Best regards,
baolu
Cc: Lu Baolu
Signed-off-by: Jacob Pan
---
On Fri, Mar 20, 2020 at 10:41:44AM +, John Garry wrote:
> On 19/03/2020 18:43, Jean-Philippe Brucker wrote:
> > On Thu, Mar 19, 2020 at 12:54:59PM +, John Garry wrote:
> > > Hi Will,
> > >
> > > >
> > > > On Thu, Jan 02, 2020 at 05:44:39PM +, John Garry wrote:
> > > > > And for the
On 19/03/2020 18:43, Jean-Philippe Brucker wrote:
On Thu, Mar 19, 2020 at 12:54:59PM +, John Garry wrote:
Hi Will,
On Thu, Jan 02, 2020 at 05:44:39PM +, John Garry wrote:
And for the overall system, we have:
PerfTop: 85864 irqs/sec kernel:89.6% exact: 0.0% lost: 0/34434
On Tue, 2020-02-25 at 12:23 +0530, Sreekanth Reddy wrote:
> On Tue, Feb 25, 2020 at 11:51 AM Abdul Haleem
> wrote:
> >
> > On Fri, 2020-01-17 at 18:21 +0530, Abdul Haleem wrote:
> > > On Thu, 2020-01-16 at 09:44 -0800, Christoph Hellwig wrote:
> > > > Hi Abdul,
> > > >
> > > > I think the problem
On Fri, Mar 20, 2020 at 10:29:55AM +0100, Jean-Philippe Brucker wrote:
> > - success:
> > - *pasid = svm->pasid;
> > +success:
> > + sdev->pasid = svm->pasid;
> > + sdev->sva.dev = dev;
> > + if (sd)
> > + *sd = sdev;
>
> One thing that might be missing: calling bind() multiple
On Mon, Feb 24, 2020 at 03:26:36PM -0800, Jacob Pan wrote:
> Query Shared Virtual Address/Memory capability is a generic feature.
> SVA feature check is the required first step before calling
> iommu_sva_bind_device().
>
> VT-d checks SVA feature enabling at per IOMMU level during this step,
>
Hi Jacob,
I think this step is really useful and the patch looks good overall,
thanks for doing this. Some commments inline
On Mon, Feb 24, 2020 at 03:26:37PM -0800, Jacob Pan wrote:
> This patch is an initial step to replace Intel SVM code with the
> following IOMMU SVA ops:
>
From: Joerg Roedel
Some unrelated changes in the iommu code caused a new warning to
appear in the arm-smmu driver:
CC drivers/iommu/arm-smmu.o
drivers/iommu/arm-smmu.c: In function 'arm_smmu_add_device':
drivers/iommu/arm-smmu.c:1441:2: warning: 'smmu' may be used uninitialized in
this
From: Joerg Roedel
The term dev_iommu aligns better with other existing structures and
their accessor functions.
Cc: Greg Kroah-Hartman
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 28
From: Joerg Roedel
Move the iommu_fwspec pointer in struct device into struct dev_iommu.
This is a step in the effort to reduce the iommu related pointers in
struct device to one.
Cc: Greg Kroah-Hartman
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Signed-off-by: Joerg Roedel
---
drivers/iommu/qcom_iommu.c | 61 ++
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
From: Joerg Roedel
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-gart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/tegra-gart.c
From: Joerg Roedel
There are users outside of the IOMMU code that need to call that
function. Define it for !CONFIG_IOMMU_API too so that compilation does
not break.
Reported-by: kbuild test robot
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 4
Hi,
here is the third version of the changes to move iommu_fwspec out of
'struct device'. Previous versions of this patch-set can be found here:
v2: https://lore.kernel.org/lkml/20200310091229.29830-1-j...@8bytes.org/
v1:
From: Joerg Roedel
Move the pointer for iommu private data from struct iommu_fwspec to
struct dev_iommu.
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Joerg Roedel
Add dev_iommu_priv_get/set() functions to access per-device iommu
private data. This makes it easier to move the pointer to a different
location.
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h |
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/ipmmu-vmsa.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/virtio-iommu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.c| 13 ++---
drivers/iommu/mtk_iommu_v1.c | 14 +++---
2 files changed, 13 insertions(+), 14 deletions(-)
diff
From: Joerg Roedel
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Tested-by: Hanjun Guo
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions in the code.
Tested-by: Hanjun Guo
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu-v3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions and simplify the code
where possible with this change.
Tested-by: Will Deacon # arm-smmu
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu.c | 57 +---
1 file changed, 30 insertions(+),
From: Joerg Roedel
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Joerg,
On 2020/3/19 22:03, Joerg Roedel wrote:
Hi Baolu,
On Sat, Mar 14, 2020 at 09:07:01AM +0800, Lu Baolu wrote:
+static int iommu_group_change_def_domain(struct iommu_group *group, int type)
+{
+ struct group_device *grp_dev, *temp;
+ struct iommu_domain *new, *old;
+
With the def_domain_type introduced, iommu default domain framework
is now able to determine a proper default domain for a group. Let's
use this to configure a group's default domain.
If unlikely a device requires a special default domain type other
than that in use, iommu probe procedure will
On 2020/3/20 14:30, Tom Murphy wrote:
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
Can you please take a look at this patch series?
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote:
>
> Remove all IOVA handling code from the
Any news on this? Is there anyone who wants to try and fix this possible bug?
On Mon, 23 Dec 2019 at 03:41, Jani Nikula wrote:
>
> On Mon, 23 Dec 2019, Robin Murphy wrote:
> > On 2019-12-23 10:37 am, Jani Nikula wrote:
> >> On Sat, 21 Dec 2019, Tom Murphy wrote:
> >>> This patchset converts
81 matches
Mail list logo
