From: Suravee Suthikulpanit
When a device switches domain, IOMMU driver detach device from the old
domain, and attach device to the new domain. During this period
the host table root pointer is not set, which means DMA translation
should be marked as invalid (clear TV bit).
So, clear the TV bit
From: Suravee Suthikulpanit
When a VM is terminated, the VFIO driver detaches all pass-through
devices from VFIO domain by clearing domain id and page table root
pointer from each device table entry (DTE), and then invalidates
the DTE. Then, the VFIO driver unmap pages and invalidate IOMMU pages.
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_dma as
reserved regions using the appropriate callback in iommu_ops.
Signed-off-by: Pierre Morel
---
drivers/iommu/s390-iommu.c | 29 +++
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_dma as
reserved regions using the appropriate callback in iommu_ops.
The reserved region may later be retrieved from sysfs or from
the vfi
Hi Alex,
On 1/15/19 12:04 AM, Alex Williamson wrote:
> On Mon, 14 Jan 2019 21:48:06 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 1/12/19 12:58 AM, Alex Williamson wrote:
>>> On Tue, 8 Jan 2019 11:26:30 +0100
>>> Eric Auger wrote:
>>>
This patch adds a new 64kB region aiming to repo
The addresses within a single page are always contiguous, so it's
not so necessary to allocate one single page from CMA area. Since
the CMA area has a limited predefined size of space, it might run
out of space in some heavy use case, where there might be quite a
lot CMA pages being allocated for s
Hi Jean,
On 1/11/19 12:06 PM, Jean-Philippe Brucker wrote:
> On 10/01/2019 18:45, Jacob Pan wrote:
>> On Tue, 8 Jan 2019 11:26:26 +0100
>> Eric Auger wrote:
>>
>>> From: Jacob Pan
>>>
>>> Device faults detected by IOMMU can be reported outside IOMMU
>>> subsystem for further processing. This pa
Hi Alex,
On 1/11/19 11:50 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:16 +0100
> Eric Auger wrote:
>
>> 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 su
Hi Jean,
On 1/11/19 6:46 PM, Jean-Philippe Brucker wrote:
> On 08/01/2019 10:26, Eric Auger wrote:
>> 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
On Tue, 15 Jan 2019 18:37:30 +0100
Pierre Morel wrote:
> The s390 iommu can only allow DMA transactions between the zPCI device
> entries start_dma and end_dma.
>
> Let's declare the regions before start_dma and after end_dma as
> reserved regions using the appropriate callback in iommu_ops.
>
On Tue, Jan 15, 2019 at 05:23:22PM +0100, Joerg Roedel wrote:
> Right, I thought about that too, but didn't find a generic way to check
> for all the cases. There are various checks that could be done:
>
> 1) Check if SWIOTLB is initialized at all, if not, return
> SIZE_MAX as the l
17.12.2018 12:14, Joerg Roedel пишет:
> On Wed, Dec 12, 2018 at 11:38:43PM +0300, Dmitry Osipenko wrote:
>> Dmitry Osipenko (24):
>> iommu/tegra: gart: Remove pr_fmt and clean up includes
>> iommu/tegra: gart: Clean up driver probe errors handling
>> iommu/tegra: gart: Ignore devices without
On Tue, Jan 15, 2019 at 02:37:54PM +0100, Christoph Hellwig wrote:
> > +size_t dma_direct_max_mapping_size(struct device *dev)
> > +{
> > + /*
> > +* Return the minimum of the direct DMA limit and the SWIOTLB limit.
> > +* Since direct DMA has no limit, it is fine to just return the SWIOT
On Mon, Jan 14, 2019 at 04:38:20PM +, Robin Murphy wrote:
> On 14/01/2019 16:09, Thierry Reding wrote:
> > On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
> > > This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
> > >
> > > That patch broke IOMMU support for device
On Tue, Jan 15, 2019 at 02:56:34PM +0100, Christian Zigotzky wrote:
> On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
>> On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
>>> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
>>> generic direct mappin
Hey Jacob,
> On 7 Jan 2019, at 20:04, Jacob Pan wrote:
>
> On Wed, 5 Dec 2018 17:19:35 +
> James Sewart wrote:
>
>> Hey,
>>
>> There exists an issue in the logic used to determine domain
>> association with devices. Currently the driver uses
>> find_or_alloc_domain to either reuse an exis
On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma
> +size_t dma_direct_max_mapping_size(struct device *dev)
> +{
> + /*
> + * Return the minimum of the direct DMA limit and the SWIOTLB limit.
> + * Since direct DMA has no limit, it is fine to just return the SWIOTLB
> + * limit.
> + */
> + return swiotlb_max_mapping_siz
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
> generic direct mapping bypass)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 21074ef03c0816ae158721a78cab
On Tue, 15 Jan 2019 10:10:21 +0800
Lu Baolu wrote:
> Hi,
>
> On 1/14/19 8:26 PM, Jonathan Cameron wrote:
> > On Thu, 10 Jan 2019 11:00:23 +0800
> > Lu Baolu wrote:
> >
> >> When multiple domains per device has been enabled by the
> >> device driver, the device will tag the default PASID for
From: Joerg Roedel
The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.
Signed-off-by: Joerg Roedel
---
include/linux/dma-mappi
From: Joerg Roedel
Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c | 10 ++
1 file changed, 6 insertions(+),
From: Joerg Roedel
The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 5 +
kernel/dma/swiotlb.c| 5 +
2 files changed,
Hi,
here is the second version of my patch-set to fix a DMA
mapping size issue triggered by the virtio-blk driver.
The problem is a limitation of the SWIOTLB implementation,
which does not support allocations larger than 256kb. When
the virtio-blk driver tries to read/write a block larger
than t
On Tue, Jan 15, 2019 at 09:37:42AM +0100, Joerg Roedel wrote:
> On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> > Which would be fine especially if we can manage not to introduce a bunch
> > of indirect calls all over the place and hurt performance.
>
> Which indirect calls?
On Mon, Jan 14, 2019 at 03:48:47PM -0500, Michael S. Tsirkin wrote:
> I think you are exaggerating a little here. Limited access with e.g.
> need to flush caches is common on lower end but less common on higher
> end systems used for virtualization. As you point out that changes with
> e.g. SEV b
On Mon, Jan 14, 2019 at 04:59:27PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 14, 2019 at 03:49:07PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 11, 2019 at 10:12:31AM +0100, Joerg Roedel wrote:
> > > On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Why not
Some systems implement virtio-iommu as a PCI endpoint. The operating
system needs to discover the relationship between IOMMU and masters long
before the PCI endpoint gets probed. Add a PCI child node to describe the
virtio-iommu device.
The virtio-pci-iommu is conceptually split between a PCI prog
Implement the virtio-iommu driver, following specification v0.9 [1].
This is a simple rebase onto Linux v5.0-rc2. We now use the
dev_iommu_fwspec_get() helper introduced in v5.0 instead of accessing
dev->iommu_fwspec, but there aren't any functional change from v6 [2].
Our current goal for virtio
The nature of a virtio-mmio node is discovered by the virtio driver at
probe time. However the DMA relation between devices must be described
statically. When a virtio-mmio node is a virtio-iommu device, it needs an
"#iommu-cells" property as specified by bindings/iommu/iommu.txt.
Otherwise, the v
The event queue offers a way for the device to report access faults from
endpoints. It is implemented on virtqueue #1. Whenever the host needs to
signal a fault, it fills one of the buffers offered by the guest and
interrupts it.
Tested-by: Bharat Bhushan
Tested-by: Eric Auger
Reviewed-by: Eric
When the device offers the probe feature, send a probe request for each
device managed by the IOMMU. Extract RESV_MEM information. When we
encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
This will tell other subsystems that there is no need to map the MSI
doorbell in the virt
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio transport without emulating page
tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code transforms calls coming from the IOMMU API into
correspondi
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Acked-by: Bjorn Helgaas
Signed-off-by: Jean-Philippe Brucker
---
drivers/pci/of.
In PCI root complex nodes, the iommu-map property describes the IOMMU that
translates each endpoint. On some platforms, the IOMMU itself is presented
as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). This isn't supported
by the current OF driver, which expects all endpoints to have an IOMMU.
All
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use
the generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 21074ef03c0816ae158721a78cabe9035938
I was able to compile the kernel for the AmigaOne X1000 (Nemo b
Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use
the dma_direct mapping routines)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f
Error message:
arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): und
On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> Which would be fine especially if we can manage not to introduce a bunch
> of indirect calls all over the place and hurt performance.
Which indirect calls? In case of unset dma_ops the DMA-API functions
call directly into the dm
Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use
the dma-direct allocator for coherent platforms)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
Link to the Git:
http://git.infradead.org/users/
39 matches
Mail list logo
