FWIW,
Acked-by: Robin Murphy
I guess you're hoping for Joerg to pick this up? However I wouldn't
foresee any major conflicts if you do need to take it through the OF tree.
Cheers,
Robin.
Signed-off-by: Rob Herring
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
d
On 2023-09-04 16:34, Jean-Philippe Brucker wrote:
On Fri, Aug 25, 2023 at 05:21:26PM +0200, Niklas Schnelle wrote:
Add ops->flush_iotlb_all operation to enable virtio-iommu for the
dma-iommu deferred flush scheme. This results inn a significant increase
in
in performance in exchange for a wi
On 2023-09-18 12:51, Niklas Schnelle wrote:
Pull out the sync operation from viommu_map_pages() by implementing
ops->iotlb_sync_map. This allows the common IOMMU code to map multiple
elements of an sg with a single sync (see iommu_map_sg()). Furthermore,
it is also a requirement for IOMMU_CAP_DEF
On 2023-09-19 09:15, Jean-Philippe Brucker wrote:
On Mon, Sep 18, 2023 at 05:37:47PM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 17dcd826f5c2..3649586f0e5c 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
On 22/09/2023 1:41 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote:
They're not strictly equivalent: this check works around a temporary issue
with the IOMMU core, which calls map/unmap before the domain is
finalized.
Where? The above points to
On 22/09/2023 5:27 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 02:13:18PM +0100, Robin Murphy wrote:
On 22/09/2023 1:41 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote:
They're not strictly equivalent: this check works around a temp
On 2023-09-23 00:33, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote:
virtio isn't setting ops->pgsize_bitmap for the sake of direct mappings
either; it sets it once it's discovered any instance, since apparently it's
assuming that all inst
On 2023-09-25 14:29, Jason Gunthorpe wrote:
On Mon, Sep 25, 2023 at 02:07:50PM +0100, Robin Murphy wrote:
On 2023-09-23 00:33, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote:
virtio isn't setting ops->pgsize_bitmap for the sake of direct mapping
On 2021-10-04 12:44, Will Deacon wrote:
On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote:
The IOVA domain structure is a bit overloaded, holding:
- IOVA tree management
- FQ control
- IOVA rcache memories
Indeed only a couple of IOVA users use the rcache, and only dma-iommu.c
uses the
On 2021-11-16 14:21, John Garry wrote:
On 04/10/2021 12:44, Will Deacon wrote:
On Fri, Sep 24, 2021 at 06:01:52PM +0800, John Garry wrote:
The IOVA domain structure is a bit overloaded, holding:
- IOVA tree management
- FQ control
- IOVA rcache memories
Indeed only a couple of IOVA users use t
*be*
more than one caller in the first place, but hey.
Acked-by: Robin Murphy
Signed-off-by: John Garry
Acked-by: Will Deacon
Reviewed-by: Xie Yongji
Acked-by: Jason Wang
Acked-by: Michael S. Tsirkin
---
Differences to v1:
- Separate out from original series which conflicts with Robin'
Hi John,
On 2021-12-20 08:49, John Garry wrote:
On 24/09/2021 11:01, John Garry wrote:
Only dma-iommu.c and vdpa actually use the "fast" mode of IOVA alloc and
free. As such, it's wasteful that all other IOVA domains hold the rcache
memories.
In addition, the current IOVA domain init implement
On 2022-01-26 13:55, John Garry wrote:
Currently the rcache structures are allocated for all IOVA domains, even if
they do not use "fast" alloc+free interface. This is wasteful of memory.
In addition, fails in init_iova_rcaches() are not handled safely, which is
less than ideal.
Make "fast" use
On 2022-01-28 11:32, John Garry wrote:
On 26/01/2022 17:00, Robin Murphy wrote:
As above, I vote for just forward-declaring the free routine in iova.c
and keeping it entirely private.
BTW, speaking of forward declarations, it's possible to remove all the
forward declarations in iova.
Make "fast" users call a separate rcache init explicitly, which includes
error checking.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
Differences to v1:
- Drop stubs for iova_domain_init_rcaches() and iova_domain_free_rcaches()
- Use put_iova_domain() in vdpa code
diff --git
On 2022-03-14 22:42, Dmitry Osipenko wrote:
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that is
On 2022-03-23 07:15, Christian König wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as DEVICE_nGnRE, it can not support unaligned
access.
Well that some ARM boards doesn't allow unaligned access to MMIO
On 2022-03-23 10:11, Gerd Hoffmann wrote:
On Wed, Mar 23, 2022 at 09:45:13AM +, Robin Murphy wrote:
On 2022-03-23 07:15, Christian K�nig wrote:
Am 22.03.22 um 10:34 schrieb Cong Liu:
qxl use ioremap to map ram_header and rom, in the arm64 implementation,
the device is mapped as
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their pr
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
b
On 2021-03-10 09:25, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:
On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead
On 2021-03-11 08:26, Christoph Hellwig wrote:
On Wed, Mar 10, 2021 at 06:39:57PM +, Robin Murphy wrote:
Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.
Yes, my initial thought was to directly
On 2021-03-15 08:33, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote:
Let me know what you think of the version here:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
I'll happily switch the patch to you as the auth
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
themselves.
Actually, now that both AMD and Intel are converted over, maybe it's
finally time to
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms. For now it describes the relation between
virtio-iommu and the endpoints it manages. Supporting that requires
three steps:
(1) acpi_viot_init(): parse the VIOT t
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
On 2021-03-30 14:11, Will Deacon wrote:
On Tue, Mar 16, 2021 at 04:38:22PM +0100
On 2021-03-31 16:32, Will Deacon wrote:
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
On 2021-03-31 12:49, Will Deacon wrote:
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
On 2021-03-30 14:58, Will Deacon wrote:
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin
On 2021-03-16 15:38, Christoph Hellwig wrote:
[...]
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index f1e38526d5bd40..996dfdf9d375dd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3
Hi Andi,
On 2021-06-03 01:41, Andi Kleen wrote:
In some situations when we know swiotlb is forced and we have
to deal with untrusted hosts, it's useful to know if a mapping
was in the swiotlb or not. This allows us to abort any IO
operation that would access memory outside the swiotlb.
Otherwis
On 2021-06-03 01:41, Andi Kleen wrote:
swiotlb currently only uses the start address of a DMA to check if something
is in the swiotlb or not. But with virtio and untrusted hosts the host
could give some DMA mapping that crosses the swiotlb boundaries,
potentially leaking or corrupting data. Add s
On 2021-06-10 08:51, Jean-Philippe Brucker wrote:
dma-iommu uses the address bounds described in domain->geometry during
IOVA allocation. The address size parameters of iommu_setup_dma_ops()
are useful for describing additional limits set by the platform
firmware, but aren't needed for drivers th
On 2021-06-18 08:41, Jean-Philippe Brucker wrote:
Hi Eric,
On Wed, Jun 16, 2021 at 11:35:13AM +0200, Eric Auger wrote:
-const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
- const u32 *id_in)
+int iort_iommu_configure_id(struct devic
On 2021-06-18 11:50, Jean-Philippe Brucker wrote:
On Wed, Jun 16, 2021 at 06:02:39PM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c62e19bed302..175f8eaeb5b3 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1322,7
obtained from dev->dma_range_map on Arm.
But removing them on Arm isn't completely straightforward so is left for
future work. As an intermediate step, simplify the x86 callers by
passing dummy limits.
Reviewed-by: Robin Murphy
Signed-off-by: Jean-Philippe Brucker
---
include/linux/dma-
On 2021-06-18 16:20, Jean-Philippe Brucker wrote:
Extract generic DMA setup code out of IORT, so it can be reused by VIOT.
Keep it in drivers/acpi/arm64 for now, since it could break x86
platforms that haven't run this code so far, if they have invalid
tables.
Reviewed-by: Robin M
acpi_iommu_fwspec_init() helper.
Reviewed-by: Robin Murphy
Signed-off-by: Jean-Philippe Brucker
---
include/acpi/acpi_bus.h | 3 ++
include/linux/acpi_iort.h | 8 ++---
drivers/acpi/arm64/iort.c | 74 +--
drivers/acpi/scan.c | 73
On 2021-07-09 12:43, Wei Liu wrote:
Some devices may have been claimed by the hypervisor already. One such
example is a user can assign a NIC for debugging purpose.
Ideally Linux should be able to tell retrieve that information, but
there is no way to do that yet. And designing that new mechanis
On 2021-07-09 12:43, Wei Liu wrote:
Microsoft Hypervisor provides a set of hypercalls to manage device
domains. The root kernel should parse the DMAR so that it can program
the IOMMU (with hypercalls) correctly.
The DMAR code was designed to work with Intel IOMMU only. Add two more
parameters to
On 2021-08-03 09:54, Yongji Xie wrote:
On Tue, Aug 3, 2021 at 3:41 PM Jason Wang wrote:
在 2021/7/29 下午3:34, Xie Yongji 写道:
Export alloc_iova_fast() and free_iova_fast() so that
some modules can use it to improve iova allocation efficiency.
It's better to explain why alloc_iova() is not su
On 2021-08-04 06:02, Yongji Xie wrote:
On Tue, Aug 3, 2021 at 6:54 PM Robin Murphy wrote:
On 2021-08-03 09:54, Yongji Xie wrote:
On Tue, Aug 3, 2021 at 3:41 PM Jason Wang wrote:
在 2021/7/29 下午3:34, Xie Yongji 写道:
Export alloc_iova_fast() and free_iova_fast() so that
some modules can use
On 2022-11-15 02:28, leo-...@hotmail.com wrote:
Hi,
Why doesn't the arm smmu driver for Linux support debugfs ?
Because nobody's ever written any debugfs code for it.
Are there any historical reasons?
Only that so far nobody's needed to.
TBH, arm-smmu is actually quite straightfor
On 2023-01-06 16:42, Jason Gunthorpe wrote:
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
FWIW, since we *do* have two variants already
On 2023-01-18 18:00, Jason Gunthorpe wrote:
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
On 2022-04-05 17:16, Jason Gunthorpe wrote:
vdpa and usnic are trying to test if IOMMU_CACHE is supported. The correct
way to do this is via dev_is_dma_coherent()
Not necessarily...
Disregarding the complete disaster of PCIe No Snoop on Arm-Based
systems, there's the more interesting effectiv
On 2022-04-06 15:14, Jason Gunthorpe wrote:
On Wed, Apr 06, 2022 at 03:51:50PM +0200, Christoph Hellwig wrote:
On Wed, Apr 06, 2022 at 09:07:30AM -0300, Jason Gunthorpe wrote:
Didn't see it
I'll move dev_is_dma_coherent to device.h along with
device_iommu_mapped() and others then
No. It it
On 2022-04-07 14:59, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 07:18:48AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, April 7, 2022 1:17 AM
On Wed, Apr 06, 2022 at 06:10:31PM +0200, Christoph Hellwig wrote:
On Wed, Apr 06, 2022 at 01:06:23PM -0300, Jason Gunthorpe wro
On 2022-06-06 07:19, Nicolin Chen wrote:
The core code should not call an iommu driver op with a struct device
parameter unless it knows that the dev_iommu_priv_get() for that struct
device was setup by the same driver. Otherwise in a mixed driver system
the iommu_priv could be casted to the wron
On 2022-06-06 17:51, Nicolin Chen wrote:
Hi Robin,
On Mon, Jun 06, 2022 at 03:33:42PM +0100, Robin Murphy wrote:
On 2022-06-06 07:19, Nicolin Chen wrote:
The core code should not call an iommu driver op with a struct device
parameter unless it knows that the dev_iommu_priv_get() for that
Use the new interface to check the capability for our device
specifically.
Signed-off-by: Robin Murphy
---
drivers/vhost/vdpa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 935a1d0ddb97..4cfebcc24a03 100644
--- a/drivers
On 2022-06-17 03:53, Tian, Kevin wrote:
From: Nicolin Chen
Sent: Friday, June 17, 2022 6:41 AM
...
- if (resv_msi) {
+ if (resv_msi && !domain->msi_cookie) {
ret = iommu_get_msi_cookie(domain->domain,
resv_msi_base);
if (ret && ret != -ENODEV)
On 2022-06-16 23:23, Nicolin Chen wrote:
On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
The domain->ops validation was added, as a precaution, for mixed-driver
systems. However, at this moment only one iommu driver is possible. So
remove it.
It's true on a physical platform. But
On 2022-06-24 14:16, Jason Gunthorpe wrote:
On Wed, Jun 22, 2022 at 08:54:45AM +0100, Robin Murphy wrote:
On 2022-06-16 23:23, Nicolin Chen wrote:
On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
The domain->ops validation was added, as a precaution, for mixed-driver
syst
On 2022-05-27 00:50, Dmitry Osipenko wrote:
Hello,
This patchset introduces memory shrinker for the VirtIO-GPU DRM driver
and adds memory purging and eviction support to VirtIO-GPU driver.
The new dma-buf locking convention is introduced here as well.
During OOM, the shrinker will release BOs
On 2022-06-29 20:47, Nicolin Chen wrote:
On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
It's not used in VFIO context. "return 0" just satisfy the iommu
framework to go ahead. and yes, here we only allow the shared
"map
On 2022-06-30 21:36, Nicolin Chen wrote:
Cases like VFIO wish to attach a device to an existing domain that was
not allocated specifically from the device. This raises a condition
where the IOMMU driver can fail the domain attach because the domain and
device are incompatible with each other.
Th
On 01/07/2022 5:43 pm, Nicolin Chen wrote:
On Fri, Jul 01, 2022 at 11:21:48AM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 2ed3594f384e..072cac5ab5a4 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers
On 2022-06-08 12:48, Robin Murphy wrote:
Use the new interface to check the capability for our device
specifically.
Just checking in case this got lost - vdpa is now the only remaining
iommu_capable() user in linux-next, and I'd like to be able to remove
the old interface next
On 2022-07-14 12:11, Jean-Philippe Brucker wrote:
Fix virtio-iommu interaction with VFIO, as VFIO now requires
IOMMU_CAP_CACHE_COHERENCY. virtio-iommu does not support non-cacheable
mappings, and always expects to be called with IOMMU_CACHE.
Can we know this is actually true though? What if the
On 2022-07-14 14:00, Jean-Philippe Brucker wrote:
On Thu, Jul 14, 2022 at 01:01:37PM +0100, Robin Murphy wrote:
On 2022-07-14 12:11, Jean-Philippe Brucker wrote:
Fix virtio-iommu interaction with VFIO, as VFIO now requires
IOMMU_CAP_CACHE_COHERENCY. virtio-iommu does not support non-cacheable
On 2022-08-18 17:38, Jean-Philippe Brucker wrote:
Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache
coherence") requires IOMMU drivers to advertise
IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does
not provide to userspace the ability to maintain coherency t
On 2022-08-19 11:38, Jean-Philippe Brucker wrote:
On Thu, Aug 18, 2022 at 09:10:25PM +0100, Robin Murphy wrote:
On 2022-08-18 17:38, Jean-Philippe Brucker wrote:
Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache
coherence") requires IOMMU drivers to
ure bit, PROBE property and ATTACH/MAP
flags.
Interpreted in the *correct* context, I do think this is objectively
less wrong than before. We can't guarantee that the underlying
implementation will respect cacheable mappings, but it is true that we
can do everything in our p
On 2022-09-07 14:47, Jason Gunthorpe wrote:
On Wed, Sep 07, 2022 at 02:41:54PM +0200, Joerg Roedel wrote:
On Mon, Aug 15, 2022 at 11:14:33AM -0700, Nicolin Chen wrote:
Provide a dedicated errno from the IOMMU driver during attach that the
reason attached failed is because of domain incompatabil
. Fix that by
updating the viommu_capable() signature after the merge.
I thought I'd called out somewhere that this was going to be a conflict,
but apparently not, sorry about that.
Acked-by: Robin Murphy
Lemme spin a patch for the outstanding LKP warning on the bus series
before that
On 2022-09-07 18:00, Jason Gunthorpe wrote:
On Wed, Sep 07, 2022 at 03:23:09PM +0100, Robin Murphy wrote:
On 2022-09-07 14:47, Jason Gunthorpe wrote:
On Wed, Sep 07, 2022 at 02:41:54PM +0200, Joerg Roedel wrote:
On Mon, Aug 15, 2022 at 11:14:33AM -0700, Nicolin Chen wrote:
Provide a
On 2022-09-08 01:43, Jason Gunthorpe wrote:
On Wed, Sep 07, 2022 at 08:41:13PM +0100, Robin Murphy wrote:
FWIW, we're now very close to being able to validate dev->iommu against
where the domain came from in core code, and so short-circuit ->attach_dev
entirely if they don't
On 2022-09-14 18:58, Nicolin Chen wrote:
On Wed, Sep 14, 2022 at 10:49:42AM +0100, Jean-Philippe Brucker wrote:
External email: Use caution opening links or attachments
On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote:
On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Bru
On 14/01/2019 18:20, Michael S. Tsirkin wrote:
On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
On 2019/1/14 下午5:50, Christoph Hellwig wrote:
On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +08
On 22/07/2019 15:55, Eric Auger wrote:
Do not call dma_max_mapping_size for devices that have no DMA
mask set, otherwise we can hit a NULL pointer dereference.
This occurs when a virtio-blk-pci device is protected with
a virtual IOMMU.
Fixes: e6d6dd6c875e ("virtio: Introduce virtio_max_dma_size
mmu
driver which uses the dma-iommu api uses gfp_atomic in it's
iommu_ops::map function. But doing this wastes the memory allocators
atomic pools.
Looks reasonable to me - once we get the merges sorted out I'll take a
look at propagating the flags through to io-pgtable for the SMMU drivers
On 15/08/2019 12:09, Tom Murphy wrote:
Handle devices which defer their attach to the iommu in the dma-iommu api
Other than nitpicking the name (I'd lean towards something like
iommu_dma_deferred_attach),
Reviewed-by: Robin Murphy
Signed-off-by: Tom Murphy
---
drivers/iomm
s.
Reviewed-by: Robin Murphy
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 906b7fa14d3c..b9a3ab02434b 100644
--- a/drivers/iommu/dma-
On 14/02/18 15:26, Alex Williamson wrote:
On Wed, 14 Feb 2018 14:53:40 +
Jean-Philippe Brucker wrote:
When enabling both VFIO and VIRTIO_IOMMU modules, automatically select
VFIO_IOMMU_TYPE1 as well.
Signed-off-by: Jean-Philippe Brucker
---
drivers/vfio/Kconfig | 2 +-
1 file changed,
On 21/03/18 13:14, Jean-Philippe Brucker wrote:
On 21/03/18 06:43, Tian, Kevin wrote:
[...]
+
+#include
+
+#define MSI_IOVA_BASE 0x800
+#define MSI_IOVA_LENGTH0x10
this is ARM specific, and according to virtio-iommu spec isn't it
better probed
On 14/02/18 14:53, Jean-Philippe Brucker wrote:
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio-mmio transport without emulating
page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code tran
On 14/02/18 14:53, Jean-Philippe Brucker wrote:
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 th
On 27/06/18 18:46, Rob Herring wrote:
On Tue, Jun 26, 2018 at 11:59 AM Jean-Philippe Brucker
wrote:
On 25/06/18 20:27, Rob Herring wrote:
On Thu, Jun 21, 2018 at 08:06:51PM +0100, Jean-Philippe Brucker wrote:
A virtio-mmio node may represent a virtio-iommu device. This is discovered
by the v
On 12/10/18 20:41, Bjorn Helgaas wrote:
s/iommu/IOMMU/ in subject
On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote:
Using the iommu-map binding, endpoints in a given PCI domain can be
managed by different IOMMUs. Some virtual machines may allow a subset of
endpoints to bypa
On 17/10/18 16:14, Michael S. Tsirkin wrote:
On Mon, Oct 15, 2018 at 08:46:41PM +0100, Jean-philippe Brucker wrote:
[Replying with my personal address because we're having SMTP issues]
On 15/10/2018 11:52, Michael S. Tsirkin wrote:
On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
On 2018-12-12 3:27 pm, Auger Eric wrote:
Hi,
On 12/12/18 3:56 PM, Michael S. Tsirkin wrote:
On Fri, Dec 07, 2018 at 06:52:31PM +, Jean-Philippe Brucker wrote:
Sorry for the delay, I wanted to do a little more performance analysis
before continuing.
On 27/11/2018 18:10, Michael S. Tsirkin
introduced.
cc: Benjamin Herrenschmidt
cc: David Gibson
cc: Michael Ellerman
cc: Paul Mackerras
cc: Michael Roth
cc: Alexey Kardashevskiy
cc: Paul Burton
cc: Robin Murphy
cc: Bartlomiej Zolnierkiewicz
cc: Marek Szyprowski
cc: Christoph Hellwig
Suggested-by: Michael S. Tsirkin
Signed-off-by: Ram
On 2019-12-23 10:37 am, Jani Nikula wrote:
On Sat, 21 Dec 2019, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver
which causes a huge amount of artifacts on the screen of my
laptop. You can
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
With the built-in topology description in place, x86 platforms can now
use the virtio-iommu.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
Hardware platforms usually describe the IOMMU topology using either
device-tree pointers or vendor-specific ACPI tables. For virtual
platforms that don't provide a device-tree, the virtio-iommu device
contains a description of the endpoints it
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote:
On 14/02/2020 4:04 pm, Jean-Philippe
On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote:
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin
On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
It might be possible to remove these obstacles if necessary. If the host
uses 64k
On 2020-03-18 4:14 pm, Auger Eric wrote:
Hi,
On 3/18/20 1:00 PM, Robin Murphy wrote:
On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO
omain.
Only initialise the vdomain->viommu pointer, which denotes a finalised
domain, at the end of a successful viommu_domain_finalise().
Reviewed-by: Robin Murphy
Fixes: edcd69ab9a32 ("iommu: Add virtio-iommu driver")
Reported-by: Eric Auger
Signed-off-by: Jean-Philippe Bruc
ow
setting different page masks for each endpoint.
Reviewed-by: Robin Murphy
Reported-by: Bharat Bhushan
Signed-off-by: Jean-Philippe Brucker
---
v1->v2: Move to vdomain_finalise(), improve commit message
---
drivers/iommu/virtio-iommu.c | 14 --
1 file changed, 12 insertions(+)
On 2020-04-01 12:38 pm, Bharat Bhushan wrote:
Different endpoint can support different page size, probe
endpoint if it supports specific page size otherwise use
global page sizes.
Signed-off-by: Bharat Bhushan
---
drivers/iommu/virtio-iommu.c | 33 +++
includ
On 06/01/17 17:48, Jean-Philippe Brucker wrote:
> Hi Will,
>
> On 20/12/16 15:14, Will Deacon wrote:
>> Booting Linux on an ARM fastmodel containing an SMMU emulation results
>> in an unexpected I/O page fault from the legacy virtio-blk PCI device:
>>
>> [1.211721] arm-smmu-v3 2b40.smmu: e
On 06/01/17 21:51, Andy Lutomirski wrote:
> On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy wrote:
>> On 06/01/17 17:48, Jean-Philippe Brucker wrote:
>>> Hi Will,
>>>
>>> On 20/12/16 15:14, Will Deacon wrote:
>>>> Booting Linux on an ARM fastmodel
suitably limited for the legacy vring as per
a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
devices").
Reported-by: Jean-Philippe Brucker
Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
Signed-off-by: Robin Murphy
---
drivers/virti
On 10/01/17 13:15, Arnd Bergmann wrote:
> On Tuesday, January 10, 2017 12:26:01 PM CET Robin Murphy wrote:
>> @@ -548,6 +550,14 @@ static int virtio_mmio_probe(struct platform_device
>> *pdev)
>> if (vm_dev->version == 1)
>>
On 10/01/17 14:54, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2017 at 12:26:01PM +0000, Robin Murphy wrote:
>> Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
>> inadvertently relying on the default 32-bit DMA mask, which leads to
>> problems like rapid
suitably limited for the legacy vring as per
a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
devices").
Cc: Andy Lutomirski
Cc: Michael S. Tsirkin
Reported-by: Jean-Philippe Brucker
Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
Signed-
From: Will Deacon
Booting Linux on an ARM fastmodel containing an SMMU emulation results
in an unexpected I/O page fault from the legacy virtio-blk PCI device:
[1.211721] arm-smmu-v3 2b40.smmu: event 0x10 received:
[1.211800] arm-smmu-v3 2b40.smmu: 0xf010
[1
1 - 100 of 109 matches
Mail list logo
