On Fri, Nov 30, 2018 at 07:14:00PM +0800, John Garry wrote:
> From: Ganapatrao Kulkarni
>
> Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
> respective device NUMA node. The ternary operator which would be for
> alloc_pages_node() is tidied along with this.
>
> The moti
On Mon, Dec 10, 2018 at 09:58:54AM +0800, Lu Baolu wrote:
> Lu Baolu (12):
> iommu/vt-d: Enumerate the scalable mode capability
> iommu/vt-d: Manage scalalble mode PASID tables
> iommu/vt-d: Move page table helpers into header
> iommu/vt-d: Add 256-bit invalidation descriptor support
> io
On Sat, Dec 08, 2018 at 04:39:13PM +0800, Yong Wu wrote:
> Arvind Yadav (1):
> iommu/mediatek: Constify iommu_ops
>
> Yong Wu (17):
> dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
> iommu/mediatek: Use a struct as the platform data
> memory: mtk-smi: Use a general config_port
On Sun, Dec 09, 2018 at 11:29:29PM +0300, Dmitry Osipenko wrote:
> Dmitry Osipenko (21):
> 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 IOMMU phandle in DT
> iommu: Introduce iot
On Fri, Dec 7, 2018 at 5:31 PM Robin Murphy wrote:
>
> Rather than checking the DMA attribute at each callsite, just pass it
> through for acpi_dma_configure() to handle directly. That can then deal
> with the relatively exceptional DEV_DMA_NOT_SUPPORTED case by explicitly
> installing dummy DMA o
When running a kernel in qemu with enough debugging options (slub-debug,
ftrace, kcov, kasan, ubsan, ...) enabled together, that results in a
slow initcall. So a 'watchdog: BUG: soft lockup' happens:
[ 44.105619] Call trace:
[ 44.106709] __slab_alloc+0x70/0x88
[ 44.107757] kmem_cache_alloc
Hi Anders,
On 11/12/2018 10:36, Anders Roxell wrote:
When running a kernel in qemu with enough debugging options (slub-debug,
ftrace, kcov, kasan, ubsan, ...) enabled together, that results in a
slow initcall. So a 'watchdog: BUG: soft lockup' happens:
[ 44.105619] Call trace:
[ 44.106709]
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Matthias Brugger
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.c| 21 -
drive
From: Joerg Roedel
These wrappers will be used to easily change the location of
the field later when all users are converted.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 14 +++---
include/linux/iommu.h | 11 +++
2 files changed, 18 insertions(+), 7 deletions(-)
di
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Will Deacon
Cc: Robin Murphy
Acked-by: Will Deacon
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu-v3.
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/ipmmu-vmsa.c | 12
1 file changed, 8 insertions(+), 4 del
Hi,
here is the second patch-set to wrap accesses to
dev->iommu_fwspec into functions so that the pointer
location can be changed more easily later on.
This version is rebased to v4.20-rc6 and addresses Robin's
comments. The Ack from will is also added.
If there are no objections I'd like to que
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Lorenzo Pieralisi
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 19 ++-
1 file ch
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletio
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Thierry Reding
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-smmu.c | 2 +-
1 file changed, 1 insertion(+
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Rob Clark
Signed-off-by: Joerg Roedel
---
drivers/iommu/qcom_iommu.c | 18 ++
1 file changed, 1
On 11.12.2018 12:53, Joerg Roedel wrote:
> On Sun, Dec 09, 2018 at 11:29:29PM +0300, Dmitry Osipenko wrote:
>> Dmitry Osipenko (21):
>> iommu/tegra: gart: Remove pr_fmt and clean up includes
>> iommu/tegra: gart: Clean up driver probe errors handling
>> iommu/tegra: gart: Ignore devices witho
On 07/12/2018 10:29, 'j...@8bytes.org' wrote:
> Hi,
>
> On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
>> btw Baolu just reminded me one thing which is worthy of noting here.
>> 'primary' vs. 'aux' concept makes sense only when we look from a device
>> p.o.v. That binding relationshi
Hi,
here is the second version of this patch-set. It replaces
the various (dev->iommu_group) checks with a function call
which better expresses their intend.
Changes to the first version are the added patch for
rcar-dmac, a driver I missed before. I also added all
Acked-By's I received on the fir
From: Joerg Roedel
Use Use device_iommu_mapped() to check if the device is
already mapped by an IOMMU.
Acked-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/o
Thanks, applied to dma-mapping for-next.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
From: Joerg Roedel
Replace the iommu-check with a proper and readable function
call.
Cc: Lorenzo Pieralisi
Acked-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/
From: Joerg Roedel
Some places in the kernel check the iommu_group pointer in
'struct device' in order to find ot whether a device is
mapped by an IOMMU.
This is not good way to make this check, as the pointer will
be moved to 'struct dev_iommu_data'. This way to make the
check is also not very
From: Joerg Roedel
Use Use device_iommu_mapped() to check if the device is
already mapped by an IOMMU.
Acked-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
drivers/dma/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma
From: Joerg Roedel
Use the new function to replace the open-coded iommu check.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Russell Currey
Cc: Sam Bobroff
Acked-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/kernel/iommu.c | 6 +++---
From: Joerg Roedel
Replace the dev->iommu_group check with a proper function
call that better reprensents its purpose.
Cc: Mathias Nyman
Acked-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
I've pulled this into the dma-mapping for-next tree now.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Next step: 977706f9755d2d697aa6f45b4f9f0e07516efeda (powerpc/dma: remove
dma_nommu_mmap_coherent)
Result: The P5020 board boots and the PASEMI onboard ethernet works.
-- Christian
On 10 December 2018 at 4:54PM, Christian Zigotzky wrote:
Next step: 64ecd2c160bbef31465c4d34efc0f076a2aad4df (pow
Hello!
On 12/11/2018 04:43 PM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Some places in the kernel check the iommu_group pointer in
> 'struct device' in order to find ot whether a device is
> mapped by an IOMMU.
>
> This is not good way to make this check, as the pointer will
> be moved to
Hi,
here is the second version of the patch-set to wrap the
invocation of iommu_ops->add/remove_device() into functions.
The functions will do more setup stuff later when the the
iommu-related pointers in 'struct device' are consolidated.
Since version one this patch-set was rebased to v4.20-rc6
From: Joerg Roedel
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 70f4
From: Joerg Roedel
Remove the iommu_ prefix from the function and a few other
static data structures so that the iommu_release_device name
can be re-used in iommu core code.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu-sysfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deleti
From: Joerg Roedel
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index c5dd6
From: Joerg Roedel
Put them into separate functions and call those where the
plain ops have been called before.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 51 +--
include/linux/iommu.h | 3 +++
2 files changed, 28 insertions(+), 26 deletion
On Tue, Dec 11, 2018 at 05:59:33PM +0300, Sergei Shtylyov wrote:
> > +static inline bool device_iommu_mapped(struct device *dev)
> > +{
> > + return (dev->iommu_group != NULL);
>
>You know that parens are unnecessary here, right? :-)
Yes, I know, but it feels incomplete to me without them :
On 10/12/2018 22:53, Michael S. Tsirkin wrote:
> On Mon, Dec 10, 2018 at 03:06:47PM +, Jean-Philippe Brucker wrote:
>> On 27/11/2018 18:53, Michael S. Tsirkin wrote:
>>> On Tue, Nov 27, 2018 at 06:10:46PM +, Jean-Philippe Brucker wrote:
On 27/11/2018 18:04, Michael S. Tsirkin wrote:
>>
> This should fix it:
...
> +#include
Not quite. Still have an issue with __phys_to_pfn(paddr)
Trying ti #include gave we a raft of redefined
macros. So I just added
#define __phys_to_pfn(paddr)PHYS_PFN(paddr)
to arch/ia64/mm/init.c
That made the build work. But boot spontaneously r
> But that might not be your fault. My ancient system is getting flaky. A v4.19
> build that
> has booted before is also resetting :-(
After a power-cycle (and some time to let the machine cool off). System now
boots
with your patch series plus the __phys_to_pfn() #define
So if you can figure t
On Tue, Dec 11, 2018 at 05:13:30PM +, Luck, Tony wrote:
> > But that might not be your fault. My ancient system is getting flaky. A
> > v4.19 build that
> > has booted before is also resetting :-(
>
> After a power-cycle (and some time to let the machine cool off). System now
> boots
> with
Next step: 7decbcfc656805603ab97206b3f816f26cd2cf7d (powerpc/dma: use
generic direct and swiotlb ops)
git checkout 7decbcfc656805603ab97206b3f816f26cd2cf7d
We have the bad commit! :-) The PASEMI onboard ethernet doesn't work
with this commit anymore.
Error messages:
[ 367.627623] pci :
Implement the virtio-iommu driver, following specification v0.9 [1].
Only minor changes since v5 [2]. I fixed issues reported by Michael and
added tags from Eric and Bharat. Thanks!
You can find Linux driver and kvmtool device on v0.9 branches [3],
module and x86 support on virtio-iommu/devel. Al
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
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
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
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.
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
On Tue, Dec 11, 2018 at 06:20:57PM +, Jean-Philippe Brucker wrote:
> Implement the virtio-iommu driver, following specification v0.9 [1].
>
> Only minor changes since v5 [2]. I fixed issues reported by Michael and
> added tags from Eric and Bharat. Thanks!
>
> You can find Linux driver and kv
On 10/12/2018 08:57, 'j...@8bytes.org' wrote:
> Hi Kevin,
>
> On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
>> Can I interpret above as that you agree with the aux domain concept (i.e. one
>> device can be linked to multiple domains) in general, and now we're just
>> trying
>> to a
On 11/12/2018 18:31, Christoph Hellwig wrote:
> On Tue, Dec 11, 2018 at 06:20:57PM +, Jean-Philippe Brucker wrote:
>> Implement the virtio-iommu driver, following specification v0.9 [1].
>>
>> Only minor changes since v5 [2]. I fixed issues reported by Michael and
>> added tags from Eric and Bh
Hi Joerg,
Please pull the following arm-smmu updates for 4.21. This includes the
clock and pm_runtime updates to the arm-smmu driver, as well as some
non-critical fixes for the arm-smmu-v3 driver.
Cheers,
Will
--->8
The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6:
On Tue, Dec 11, 2018 at 10:31:01AM -0800, Christoph Hellwig wrote:
> On Tue, Dec 11, 2018 at 06:20:57PM +, Jean-Philippe Brucker wrote:
> > Implement the virtio-iommu driver, following specification v0.9 [1].
> >
> > Only minor changes since v5 [2]. I fixed issues reported by Michael and
> > a
On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote:
> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
> kernel starts but it doesn't find any hard disks (partitions). That
> means this is also the bad commit for the P5020 board.
What are the disks hanging off ? A
Add a dma_resv parameter in pci host bridge structure
to hold resource entries list of memory regions for
which IOVAs has to reserve.
IOMMU framework reserve IOVA for this list of address
range while initializing IOMMU domain of corresponding
PCI EP connected to the HOST.
PCIe host driver will ad
PCI host has list of resource entries contain memory
address range for which IOVA address mapping has to
be reserve.
These address ranges are the address holes in
dma-ranges property.
It is similar to PCI IO resources address range
reserving in IOMMU for each EP connected to
corresponding host.
S
Few SOCs have limitation that their PCIe host
can't allow few inbound address ranges.
Allowed inbound address ranges are listed in
dma-ranges DT property and this address ranges
are required to do IOVA mapping.
Remaining address ranges have to be reserved in
IOVA mapping.
PCIe Host driver of those
IPROC host has the limitation that it can use
only those address ranges given by dma-ranges
property as inbound address.
So that the memory address holes in dma-ranges
should be reserved to allocate as DMA address.
All such reserved addresses are created as resource
entries and add to dma_resv lis
> On 12. Dec 2018, at 01:47, Benjamin Herrenschmidt
> wrote:
>
>> On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote:
>> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
>> kernel starts but it doesn't find any hard disks (partitions). That
>> means this is al
60 matches
Mail list logo
