On Tue, 2019-01-08 at 14:12 +0100, h...@lst.de wrote:
> On Tue, Jan 08, 2019 at 09:51:45AM +, Thomas Hellstrom wrote:
> > Hi, Christoph,
> >
> > On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> > > Hi Thomas,
> > >
> > > vmwgfx has been doing some odd checks based on DMA ops whic
On Tue, 8 Jan 2019, Christoph Hellwig wrote:
> From: Luis Chamberlain
>
> The last few stragglers coccinelle doesn't pick up are on driver
> specific header files. Phase those out as well as dma_alloc_coherent()
> zeroes out the memory as well now too.
You can use the --include-headers option
On Tue, 8 Jan 2019, Christoph Hellwig wrote:
> From: Luis Chamberlain
>
> dma_zalloc_coherent() is no longer needed as it has no users because
> dma_alloc_coherent() already zeroes out memory for us.
>
> The Coccinelle grammar rule that used to check for dma_alloc_coherent()
> + memset() is mo
On Tue, 8 Jan 2019, Julia Lawall wrote:
>
>
> On Tue, 8 Jan 2019, Christoph Hellwig wrote:
>
> > Hi Linus and world,
> >
> > We've always had a weird situation around dma_zalloc_coherent. To
> > safely support mapping the allocations to userspace major architectures
> > like x86 and arm have a
On Tue, 8 Jan 2019, Christoph Hellwig wrote:
> Hi Linus and world,
>
> We've always had a weird situation around dma_zalloc_coherent. To
> safely support mapping the allocations to userspace major architectures
> like x86 and arm have always zeroed allocations from dma_alloc_coherent,
> but a
On Tue, Jan 08, 2019 at 09:51:45AM +, Thomas Hellstrom wrote:
> Hi, Christoph,
>
> On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> > Hi Thomas,
> >
> > vmwgfx has been doing some odd checks based on DMA ops which rely
> > on deep DMA mapping layer internals, and I think the chan
Hi Linus and world,
We've always had a weird situation around dma_zalloc_coherent. To
safely support mapping the allocations to userspace major architectures
like x86 and arm have always zeroed allocations from dma_alloc_coherent,
but a couple other architectures were missing that zeroing either
From: Luis Chamberlain
dma_zalloc_coherent() is no longer needed as it has no users because
dma_alloc_coherent() already zeroes out memory for us.
The Coccinelle grammar rule that used to check for dma_alloc_coherent()
+ memset() is modified so that it just tells the user that the memset is
not
From: Luis Chamberlain
The last few stragglers coccinelle doesn't pick up are on driver
specific header files. Phase those out as well as dma_alloc_coherent()
zeroes out the memory as well now too.
Suggested-by: Christoph Hellwig
Signed-off-by: Luis Chamberlain
Signed-off-by: Christoph Hellwig
On 1/8/2019 12:29 PM, Bjorn Andersson wrote:
On Thu 11 Oct 02:49 PDT 2018, Vivek Gautam wrote:
Add device node for arm,mmu-500 available on sdm845.
This MMU-500 with single TCU and multiple TBU architecture
is shared among all the peripherals except gpu.
Hi Vivek,
Applying this patch togeth
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> Just use a simple if/else chain to select the DMA mode.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 25 ++---
> 1 file changed, 6 insertions(
Hi,
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
...
> intel_iommu_enabled is defined as always false for
> !CONFIG_INTEL_IOMMU,
> so remove the ifdefs around it.
>
> Signed-off-by: Christoph Hellwig
> ---
>
> -#if !defined(CONFIG_SWIOTLB) && !defined(CONFIG_INTEL_IOMMU)
> -
New iotcls were introduced to pass information about guest stage1
to the host through VFIO. Let's document the nested stage control.
Signed-off-by: Eric Auger
---
v2 -> v3:
- document the new fault API
v1 -> v2:
- use the new ioctl names
- add doc related to fault handling
---
Documentation/v
This patch registers a fault handler which records faults in
a circular buffer and then signals an eventfd. This buffer is
exposed within the fault region.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 44 -
drivers/vfio/pci/vfio_pci_private.h |
Add a new VFIO_PCI_DMA_FAULT_IRQ_INDEX index. This allows to
set/unset an eventfd that will be triggered when DMA translation
faults are detected at physical level when the nested mode is used.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 3 +++
drivers/vfio/pci/vfio_pci_in
From: Jacob Pan
DMA faults can be detected by IOMMU at device level. Adding a pointer
to struct device allows IOMMU subsystem to report relevant faults
back to the device driver for further handling.
For direct assigned device (or user space drivers), guest OS holds
responsibility to handle and r
This patch adds a new 64kB region aiming to report nested mode
translation faults.
The region contains a header with the size of the queue,
the producer and consumer indices and then the actual
fault queue data. The producer is updated by the kernel while
the consumer is updated by the userspace.
From: Jacob Pan
Device faults detected by IOMMU can be reported outside IOMMU
subsystem for further processing. This patch intends to provide
a generic device fault data such that device drivers can be
communicated with IOMMU faults without model specific knowledge.
The proposed format is the re
The bind_guest_msi() callback checks the domain
is NESTED and redirect to the dma-iommu implementation.
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu-v3.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
Implement IOMMU_INV_TYPE_TLB invalidations. When
nr_pages is null we interpret this as a context
invalidation.
Signed-off-by: Eric Auger
---
The user API needs to be refined to discriminate context
invalidations from NH_VA invalidations. Also the leaf attribute
is not yet properly handled.
v2
From: Jacob Pan
Traditionally, device specific faults are detected and handled within
their own device drivers. When IOMMU is enabled, faults such as DMA
related transactions are detected by IOMMU. There is no generic
reporting mechanism to report faults back to the in-kernel device
driver or the
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a range provided by the user.
This does not work in nested mode.
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
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
---
drivers/iommu/arm-smmu-v3.c | 124
1 file changed, 113 insertion
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: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 136 ++--
1 file chan
On set_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 guest wanted to bypass the stage 1 or induce
aborts for this STE.
Signed-off-by: Eric Auger
---
v2 -> v3:
- callba
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and remove the former
union).
arm_smmu_write_strtab_ent() is modified to write both stage
fields in the STE.
We add a nested_bypass field to the S1 configuration as the first
stage can be bypassed. Also the g
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 (h
From: Jean-Philippe Brucker
When removing a mapping from a domain, we need to send an invalidation to
all devices that might have stored it in their Address Translation Cache
(ATC). In addition with SVM, we'll need to invalidate context descriptors
of all devices attached to a live domain.
Maint
From: "Liu, Yi L"
In any virtualization use case, when the first translation stage
is "owned" by the guest OS, the host IOMMU driver has no knowledge
of caching structure updates unless the guest invalidation activities
are trapped by the virtualizer and passed down to the host.
Since the invali
From: Jacob Pan
In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on a 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 ma
From: "Liu, Yi L"
This patch adds VFIO_IOMMU_SET_PASID_TABLE ioctl which aims at
passing the virtual iommu guest configuration to the VFIO driver
downto to the iommu subsystem.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi L
Signed-off-by: Eric Auger
---
v2 -> v3:
- s/BIND_PASID_TABLE/SET_
This patch adds the VFIO_IOMMU_BIND_MSI ioctl which aims at
passing the guest MSI binding to the host.
Signed-off-by: Eric Auger
---
v2 -> v3:
- adapt to new proto of bind_guest_msi
- directly use vfio_iommu_for_each_dev
v1 -> v2:
- s/vfio_iommu_type1_guest_msi_binding/vfio_iommu_type1_bind_gu
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 prop
This series allows a virtualizer to program the nested stage mode.
This is useful when both the host and the guest are exposed with
an SMMUv3 and a PCI device is assigned to the guest using VFIO.
In this mode, the physical IOMMU must be programmed to translate
the two stages: the one set up by the
Reviewed-by: Thomas Hellstrom
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> intel_iommu_enabled is defined as always false for
> !CONFIG_INTEL_IOMMU,
> so remove the ifdefs around it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 18
Hi, Christoph,
On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote:
> Hi Thomas,
>
> vmwgfx has been doing some odd checks based on DMA ops which rely
> on deep DMA mapping layer internals, and I think the changes in
> Linux 4.21 finally broke most of these implicit assumptions.
Thanks.
Christophe Leroy writes:
> Le 04/01/2019 à 16:24, Horia Geanta a écrit :
>> On 1/4/2019 5:17 PM, Horia Geanta wrote:
>>> On 12/21/2018 10:07 AM, Christophe Leroy wrote:
>>> [snip]
IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.
>>>
37 matches
Mail list logo
