to v4.20-rc6
and I removed the pointer checks for the function pointers,
as suggested by Robin. I checked all 16 drivers and all of
them implement the add/remove_device call-backs.
Please review, if there are no objections I plan to queue
these patches in the IOMMU tree.
Thanks,
Joerg
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
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
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
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
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 Tue, Dec 11, 2018 at 08:08:48PM +, Will Deacon wrote:
> The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6:
>
> Linux 4.20-rc3 (2018-11-18 13:33:44 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
Hi,
to make progress on this, we should first agree on the protocol used
between guest and host. I have a few points to discuss on the protocol
first.
On Tue, Dec 11, 2018 at 06:20:57PM +, Jean-Philippe Brucker wrote:
> [1] Virtio-iommu specification v0.9, sources and pdf
> git://linux-ar
Hi Thierry, Hi Dmitry,
On Wed, Dec 12, 2018 at 11:24:15AM +0100, Thierry Reding wrote:
> So appart from the one issue in the "memory controller integration"
> patch this looks good and I've acked the remaining patches. Once the one
> remaining issue is fixed I think this is ready to be merged.
>
On Wed, Dec 12, 2018 at 12:04:35PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 11, 2018 at 02:43:38PM +0100, Joerg Roedel wrote:
> > Cc: Greg Kroah-Hartman
> > Acked-by: Greg Kroah-Hartman
>
> No need to have a cc: line if I have already acked it :)
Right, I'l
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 IOMMU phandle in DT
> iommu: Introduce iot
On Thu, Dec 13, 2018 at 10:45:24AM +, Will Deacon wrote:
> Joerg -- please can you take this on top of the pull request I sent already?
> Vivek included it as part of a separate series which I thought was going
> via arm-soc, but actually it needs to go with the other arm-smmu patches
> in orde
On Thu, Dec 13, 2018 at 05:19:48PM +0800, Yong Wu wrote:
> This reverts commit 82db33dc5e49fb625262d81125625d07a0d6184e.
>
> After the commit 29859aeb8a6e ("iommu/io-pgtable-arm-v7s: Abort
> allocation when table address overflows the PTE"), v7s will return fail
> if the page table allocation isn'
On Thu, Dec 13, 2018 at 08:19:28PM +, Fabrizio Castro wrote:
> Document RZ/G2E (R8A774C0) SoC bindings.
>
> Signed-off-by: Fabrizio Castro
> ---
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
On Thu, Dec 13, 2018 at 08:22:44PM +, Fabrizio Castro wrote:
> Support RZ/G2E (a.k.a. R8A774C0) IPMMU.
>
> Signed-off-by: Fabrizio Castro
> ---
> drivers/iommu/ipmmu-vmsa.c | 5 +
> 1 file changed, 5 insertions(+)
Applied, thanks.
___
iommu ma
On Mon, Dec 17, 2018 at 11:41:10AM +0530, Vinod Koul wrote:
> On 11-12-18, 14:43, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > Some places in the kernel check the iommu_group pointer in
> > 'struct device' in
Hi Marek,
thanks for the report!
On Wed, Dec 19, 2018 at 10:54:18AM +0100, Marek Szyprowski wrote:
> On 2018-12-11 16:05, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > Make sure to invoke this call-back through the proper
> > function of the IOMMU-API.
> >
From: Joerg Roedel
This check needs to be there and got lost at some point
during development. Add it again.
Fixes: 641fb0efbff0 ('iommu/of: Don't call iommu_ops->add_device directly')
Reported-by: Marek Szyprowski
Reported-by: kernelci.org bot
Signed-off-by: Joerg Roedel
Hi Marek,
On Wed, Dec 19, 2018 at 03:53:51PM +0100, Marek Szyprowski wrote:
> Yes, it fixes this issue.
Thanks a lot, patch is sent out and in iommu tree.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.lin
a774a1 support
dt-bindings: iommu: ipmmu-vmsa: Add r8a774c0 support
iommu/ipmmu-vmsa: Hook up r8a774c0 DT matching code
Ganapatrao Kulkarni (1):
iommu/dma: Use NUMA aware memory allocations in __iommu_dma_alloc_pages()
Hai Nguyen Pham (1):
iommu/ipmmu-vmsa: Hook up r8a779
SWIOTLB bounce buffering and limits the
maximum segment size in the virtio-blk driver in this case,
so that it doesn't try to do larger reads/writes.
Please review.
Thanks,
Joerg
Joerg Roedel (3):
swiotlb: Export maximum allocation size
virtio: Introduce virtio_max_dma_size()
virti
From: Joerg Roedel
The SWIOTLB implementation has a maximum size it can
allocate dma-handles for. This needs to be exported so that
device drivers don't try to allocate larger chunks.
This is especially important for block device drivers like
virtio-blk, that might do DMA through SW
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map.
The functions return the
From: Joerg Roedel
Segments can't be larger than the maximum DMA allocation
size supported by virtio 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 chang
Hi Christoph,
On Thu, Jan 10, 2019 at 02:59:52PM +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 02:44:30PM +0100, Joerg Roedel wrote:
> > The problem is a limitation of the SWIOTLB implementation,
> > which does not support allocations larger than 256kb. When
> >
On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> Why not use swiotlb_nr_tbl ? That is how drivers/gpu/drm use to figure if they
> need to limit the size of pages.
That function just exports the overall size of the swiotlb aperture, no?
What I need here is the maximum size f
On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
> Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
> all virtio devices under AMD-SEV guests?
Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
aperture, because that memory is not encrypted. The g
On Thu, Dec 20, 2018 at 03:47:28PM +, Tom Murphy wrote:
> Ah shoot, it looks like I forgot to change flush_tlb_all -> flush_iotlb_all
>
> Should I submit another patch?
Yes, please.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://li
Hi Geert,
On Thu, Dec 20, 2018 at 04:42:17PM +0100, Geert Uytterhoeven wrote:
> > - return ops->add_device(dev);
> > + if (ops)
>
> Is this sufficient? The old code checked for ops->add_device != NULL,
> too.
Robin brought up that all iommu-ops implementations support the
add_devic
On Wed, Jan 02, 2019 at 01:51:45PM +0800, Nicolas Boichat wrote:
> Does anyone have any further comment on this series? If not, which
> maintainer is going to pick this up? I assume Andrew Morton?
Probably, yes. I don't like to carry the mm-changes in iommu-tree, so
this should go through mm.
Reg
Hi,
this looks a bit confusing to me because I can see no checking whether
the device actually supports scalable mode. More below:
On Thu, Jan 10, 2019 at 11:00:21AM +0800, Lu Baolu wrote:
> +static int intel_iommu_enable_auxd(struct device *dev)
> +{
> + struct device_domain_info *info;
> +
On Sun, Dec 30, 2018 at 04:53:15PM +0100, Julia Lawall wrote:
> Delete tab aligning a statement with the right hand side of a
> preceding assignment rather than the left hand side.
>
> Found with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Applied, thanks.
__
On Wed, Jan 02, 2019 at 11:16:57PM +0200, Sakari Ailus wrote:
> Drivers such as the Intel IPU3 ImgU driver use the IOVA library to manage
> the device's own virtual address space while not implementing the IOMMU
> API. Currently the IOVA library is only compiled if the IOMMU support is
> enabled, r
On Mon, Jan 07, 2019 at 05:04:50PM +, Robin Murphy wrote:
> Whilst iommu_probe_device() does check for non-NULL ops as the previous
> code did, it does not do so in the same order relative to the other
> checks, and as a result means that -EPROBE_DEFER returned by of_xlate()
> (plus any real er
On Fri, Jan 11, 2019 at 01:04:57PM +0800, Lu Baolu wrote:
> From: Jacob Pan
>
> VT-d Rev3.0 has made a few changes to the page request interface,
>
> 1. widened PRQ descriptor from 128 bits to 256 bits;
> 2. removed streaming response type;
> 3. introduced private data that requires page respons
Hi Jean-Philippe,
On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote:
> We already do deferred flush: UNMAP requests are added to the queue by
> iommu_unmap(), and then flushed out by iotlb_sync(). So we switch to the
> host only on iotlb_sync(), or when the request queue is ful
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
Christoph Hellwig.
Please review.
Thanks,
Joerg
Joerg Roedel (3):
swiotlb: Introduce swiotlb_max_mapping_size()
dma: Introduce dma_max_mapping_size()
virtio-blk: Consider dma_max_mapping_size() for maximum segment size
drivers/block/virtio_blk.c | 10 ++
include/linux
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
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 inser
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
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 Tue, Jan 15, 2019 at 07:33:54PM +0300, Dmitry Osipenko wrote:
> Should I expect that the patches will appear in the IOMMU git and in
> -next consequently? Please let me know if there is any problem with
> the applying of the patches.
Hmm, I thought I applied these patches already, but obviously
On Wed, Jan 16, 2019 at 09:05:40AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 15, 2019 at 02:22:57PM +0100, Joerg Roedel wrote:
> > + max_size = dma_max_mapping_size(&vdev->dev);
> > +
>
>
> Should this be limited to ACCESS_PLATFORM?
>
> I see no reas
On Wed, Jan 16, 2019 at 04:33:51PM +, Jean-Philippe Brucker wrote:
> There is a fix on the list:
> https://www.spinics.net/lists/arm-kernel/msg698371.html
It is also in my tree already, I will send it upstream this week.
Regards,
Joerg
___
Hi Linus,
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.0-rc3
for you to fetch changes up to e8
On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, q
ns is called.
>
> Cc: Joerg Roedel
> Cc: Suravee Suthikulpanit
> Signed-off-by: Jerry Snitselaar
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Daniel,
On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> Note that the string of platforms which have various issues with iommu
> and igfx is very long, thus far we only disabled it where there's no
> workaround to stop it from hanging the box, but otherwise left it
> enabled. S
On Wed, Jan 16, 2019 at 08:11:44PM +0100, Gerald Schaefer wrote:
> Commit 9d3a4de4cb8d ("iommu: Disambiguate MSI region types") changed
> the reserved region type in intel_iommu_get_resv_regions() from
> IOMMU_RESV_RESERVED to IOMMU_RESV_MSI, but it forgot to also change
> the type in intel_iommu_p
On Fri, Jan 18, 2019 at 12:35:43PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 06:10:13PM +, Robin Murphy wrote:
> > It's a shame that this is pretty much a duplication of
> > debug_dma_dump_mappings(), but there seems no straightforward way to define
> > one in terms of the oth
Hi Frank,
thanks for the report!
On Tue, Jan 22, 2019 at 05:09:09PM +0100, Frank Wunderlich wrote:
> Hi,
>
> the following Patch breaks hdmi (at least) on Bananapi R2 (mt7623):
>
> a9bf2eec5a6fc01a0a5250eaf0bf61dfd382a78a "iommu/mediatek: Use helper
> functions to access dev->iommu_fwspec"
Do
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> According to our IOMMU folks there exists some desire to be able to assign
> the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> due to how the devices might be grouped in IOMMU groups. Even when you
> would no
From: Joerg Roedel
The mtk_iommu_add_device() function keeps the fwspec in an
on-stack pointer and calls mtk_iommu_create_mapping(), which
might change its source, dev->iommu_fwspec. This causes the
on-stack pointer to be obsoleted and the device
initialization to fail. Update the on-st
Hi Jean-Philippe,
thanks for all your hard work on this!
On Tue, Jan 15, 2019 at 12:19:52PM +, Jean-Philippe Brucker wrote:
> Implement the virtio-iommu driver, following specification v0.9 [1].
To make progress on this I think the spec needs to be close to something
that can be included int
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
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
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 5 +
2 files changed, 11 insertions(+)
diff --git a/include/linux
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
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 inser
limit in
dma_direct_max_mapping_size()
* Only apply the maximum segment limit in virtio-blk when
DMA-API is used for the vring
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce swiotlb_max_mapping_size()
swiotlb: Add is_swiotlb_active
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote:
> We have many reports where just having intel_iommu=on (and using the
> system normally, without any virtualization stuff going on) will cause
> unexplained GPU hangs. For those users, simply switching to
> intel_iommu=igfx_off solve
On Wed, Jan 23, 2019 at 10:28:13PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:45PM +0100, Joerg Roedel wrote:
> > +extern size_t swiotlb_max_mapping_size(struct device *dev);
>
> No need for the extern keyword on function declarations in headers.
Right
On Wed, Jan 23, 2019 at 10:27:55PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> > +bool is_swiotlb_active(void)
> > +{
> > + return !no_iotlb_memory;
> > +}
>
> As I've just introduced and fixed a bug i
On Wed, Jan 23, 2019 at 10:31:39PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:49PM +0100, Joerg Roedel wrote:
> > + max_size = virtio_max_dma_size(vdev);
> > +
> > /* Host can optionally specify maximum segment size and number of
> >
On Thu, Jan 24, 2019 at 09:42:21AM +0100, Christoph Hellwig wrote:
> Yes. But more importantly it would fix the limit for all other block
> drivers that set large segment sizes when running over swiotlb.
True, so it would be something like the diff below? I havn't worked on
the block layer, so I
Hi Lu Baolu,
On Thu, Jan 24, 2019 at 02:47:39PM +0800, Lu Baolu wrote:
> bool iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)?
Looks good. Having a function to check for enabled features is certainly
a good thing.
Regards,
Joerg
___
iommu m
On Thu, Jan 24, 2019 at 10:31:32AM +0800, Lu Baolu wrote:
> Commit 765b6a98c1de3 ("iommu/vt-d: Enumerate the scalable
> mode capability") enables VT-d scalable mode if hardware
> advertises the capability. As we will bring up different
> features and use cases to upstream in different patch
> serie
On Thu, Jan 24, 2019 at 03:10:02PM +0800, Shaokun Zhang wrote:
> drivers/iommu/dma-iommu.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.o
On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > > As I've just introduced and fixed a bug in this area in the current
> > > cycle - I don't think no_iotlb_memory is what your want
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9 +
2 files changed, 15
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.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg
reported.
For all changes to v3, a diff to v3 of the patch-set is at
the end of this email.
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce swiotlb_max_mapping_size()
swiotlb: Add is_swiotlb_active() function
dma: Introduce dma_max_mapping_size()
virtio: Introduce
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
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.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg Roedel
---
drivers/block/virtio_blk.c
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.
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 5 +
kernel/dma
/amd: Unmap all mapped pages in error path of map_sg
Joerg Roedel (1):
iommu/mediatek: Use correct fwspec in mtk_iommu_add_device()
Suravee Suthikulpanit (1):
iommu/amd: Fix IOMMU page flush when detach device from a domain
drivers/iommu/amd_iommu.c| 19
Hi Tom,
On Wed, Jan 30, 2019 at 03:10:29PM +, Lendacky, Thomas wrote:
> On 1/29/19 2:43 AM, Joerg Roedel wrote:
> > +size_t virtio_max_dma_size(struct virtio_device *vdev)
> > +{
> > + size_t max_segment_size = SIZE_MAX;
> > +
> &g
unction name in a string instead of
> __func__.
>
> Cc: Joerg Roedel
> Signed-off-by: Jerry Snitselaar
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Jan 24, 2019 at 10:31:32AM +0800, Lu Baolu wrote:
> Commit 765b6a98c1de3 ("iommu/vt-d: Enumerate the scalable
> mode capability") enables VT-d scalable mode if hardware
> advertises the capability. As we will bring up different
> features and use cases to upstream in different patch
> serie
ementation for intel_map_resource() is nearly identical to
> intel_map_page(), we just have to re-create __intel_map_single().
> dma_unmap_resource() uses intel_unmap_page() directly as the
> functions are identical.
>
> Signed-off-by: Logan Gunthorpe
> C
On Wed, Jan 30, 2019 at 01:57:58PM +0800, Peter Xu wrote:
> AMD IOMMU driver is using the clear_flush_young() to do cache flushing
> but that's actually already covered by invalidate_range(). Remove the
> extra notifier and the chunks.
>
> Signed-off-by: Peter Xu
Applied to x86/amd, thanks.
__
On Wed, Jan 30, 2019 at 01:57:57PM +0800, Peter Xu wrote:
> The change_pte() interface is tailored for PFN updates, while the
> other notifier invalidate_range() should be enough for Intel IOMMU
> cache flushing. Actually we've done similar thing for AMD IOMMU
> already in 8301da53fbc1 ("iommu/amd
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9
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.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux
larger than that, the
allocation of the dma-handle fails and an IO error is reported.
Changes to v4 are:
- Added Reviewed-by tags from Christoph
- Added missing EXPORT_SYMBOL(_GPL) lines
Please review.
Thanks,
Joerg
Joerg Roedel (5):
swiotlb: Introduce
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.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
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.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
dr
patch-set.
Michael, feel free to either apply this on-top of the patch-set or merge
the diff into patch 3, whatever you prefer.
>From 2bb95d2136280c79de9553852ee3370f6d42d7b3 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Thu, 31 Jan 2019 13:55:27 +0100
Subject: [PATCH] dma: Uninline dma_max_
From: Joerg Roedel
The only reason why swiotlb_init_with_tbl() can fail is an
allocation failure in the memblock_alloc() function. But
this function just calls panic() in case it can't fulfill
the request and never returns an error, therefore
swiotlb_init_with_tbl() also never actually re
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.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux
From: Joerg Roedel
This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API
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.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
dr
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.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
On Thu, Jan 31, 2019 at 09:43:51AM -0500, Michael S. Tsirkin wrote:
> OK. Joerg can you repost the series with this squashed
> and all acks applied?
Sure, sent out now as v6.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.or
allocations larger than 256kb. When the
virtio-blk driver tries to read/write a block larger than that, the
allocation of the dma-handle fails and an IO error is reported.
Changes to v5 are:
- Changed patch 3 to uninline dma_max_mapping_size()
Please review.
Thanks,
Joerg
Joerg Roedel
From: Joerg Roedel
This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Joerg Roedel
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 9
Hi,
On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1...@gmail.com wrote:
> +config HYPERV_IOMMU
> + bool "Hyper-V stub IOMMU support"
This is not a real IOMMU driver, it only implements IRQ remapping
capabilities. Please change the name to reflect that, e.g. to
"Hyper-V IRQ Remapping Supp
On Thu, Jan 31, 2019 at 11:56:48AM -0700, Logan Gunthorpe wrote:
> @@ -394,6 +402,10 @@ static int set_msi_sid(struct irte *irte, struct pci_dev
> *dev)
> set_irte_sid(irte, SVT_VERIFY_BUS, SQ_ALL_16,
>PCI_DEVID(PCI_BUS_NUM(data.alias),
>
701 - 800 of 3797 matches
Mail list logo
