I tried to apply the patch (AMD IOMMU driver to use dma-iommu) to linux kerenl
5.1.15 but it gives me some errors.
Downloaded the patch from https://patchwork.ozlabs.org/patch/1096015/
Is this the right way im doing?
Please let me know.
Thanks,
Sathya
- Original Message -
Hi Jacob and Yi,
On 6/9/19 9:44 PM, Jacob Pan wrote:
When supporting guest SVA with emulated IOMMU, the guest PASID
table is shadowed in VMM. Updates to guest vIOMMU PASID table
will result in PASID cache flush which will be passed down to
the host as bind guest PASID calls.
For the SL page
Hi Jacob,
On 6/9/19 9:44 PM, Jacob Pan wrote:
Make use of generic IOASID code to manage PASID allocation,
free, and lookup. Replace Intel specific code.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 11 +--
drivers/iommu/intel-pasid.c | 36
On Wed, Jun 26, 2019 at 08:56:06AM +0200, Joerg Roedel wrote:
Hi Sasha,
On Tue, Jun 25, 2019 at 11:40:25PM -0400, Sasha Levin wrote:
From: Dave Jiang
[ Upstream commit 7560cc3ca7d9d11555f80c830544e463fcdb28b8 ]
This commit was reverted upstream, please drop it from your stable
queue. It
On Mon, Jun 10, 2019 at 07:47:10PM +0100, Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
>
Hi Jean-Philippe,
On Mon, Jun 10, 2019 at 07:47:12PM +0100, Jean-Philippe Brucker wrote:
> In commit a3a195929d40 ("iommu: Add APIs for multiple domains per
> device"), the IOMMU API gained the concept of auxiliary domains (AUXD),
> which allows to control the PASID-tagged address spaces of a
As we now already have the reserved regions list, just pass that into
vfio_iommu_has_sw_msi() fn.
Signed-off-by: Shameer Kolothum
---
drivers/vfio/vfio_iommu_type1.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c
This allows the user-space to retrieve the supported IOVA
range(s), excluding any reserved regions. The implementation
is based on capability chains, added to VFIO_IOMMU_GET_INFO ioctl.
Signed-off-by: Shameer Kolothum
---
v6 --> v7
Addressed mdev case with empty iovas list(Suggested by Alex)
This checks and rejects any dma map request outside valid iova
range.
Signed-off-by: Shameer Kolothum
---
v6 --> v7
Addressed the case where a container with only an mdev device will
have an empty list(Suggested by Alex).
---
drivers/vfio/vfio_iommu_type1.c | 26 ++
1
This retrieves the reserved regions associated with dev group and
checks for conflicts with any existing dma mappings. Also update
the iova list excluding the reserved regions.
Reserved regions with type IOMMU_RESV_DIRECT_RELAXABLE are
excluded from above checks as they are considered as directly
Get a copy of iova list on _group_detach and try to update the list.
On success replace the current one with the copy. Leave the list as
it is if update fails.
Signed-off-by: Shameer Kolothum
---
drivers/vfio/vfio_iommu_type1.c | 91 +
1 file changed, 91
This introduces an iova list that is valid for dma mappings. Make
sure the new iommu aperture window doesn't conflict with the current
one or with any existing dma mappings during attach.
Signed-off-by: Shameer Kolothum
---
drivers/vfio/vfio_iommu_type1.c | 181 +++-
On Wed, Jun 26, 2019 at 12:03:02PM +0530, Vivek Gautam wrote:
> On Tue, Jun 25, 2019 at 7:09 PM Will Deacon wrote:
> >
> > On Tue, Jun 25, 2019 at 12:34:56PM +0530, Vivek Gautam wrote:
> > > On Mon, Jun 24, 2019 at 10:33 PM Will Deacon wrote:
> > > > Instead, I think this needs to be part of a
Hi Christoph / Hans,
SATA has been broken on TI platforms with LPAE, on systems with RAM addresses >
32-bits,
(e.g. DRA7 rev.H+) since v4.18.
The commit at which it breaks is
21e07dba9fb1179148089d611fc9e6e70d1887c3 ("scsi: reduce use of block bounce
buffers").
The effect is that the SATA
Hi Roger,
it seems the arm dma direct mapping code isn't doing the right thing
here. On other platforms that have > 4G memory we always use swiotlb
for bounce buffering in case a device that can't DMA to all the memory.
Arm is the odd one out and uses its own dmabounce framework instead,
but it
Dear Christoph,
Thanks for the reply.
can you please let me know which kernel has it?
Thanks,
Sathya
- Original Message -
Sender : Christoph Hellwig
Date : 2019-06-26 12:28 (GMT+5:30)
Title : Re: CMA in AMD IOMMU driver
To : Sathyavathi M
CC : null
Toms conversion of
Toms conversion of the AMD IOMMU driver to use dma-iommu adds CMA
support :)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Dear All,
This mail regarding the below communication about CMA in AMD IOMMU driver.
On Mon, Feb 02, 2015 at 10:35:36AM -0700, Alex Williamson wrote:
> [cc +joerg]
>
> On Mon, 2015-02-02 at 11:01 -0500, Mark Hounschell wrote:
> > From what I understand of CMA, and it seems provable to me, is
Hi Sasha,
On Tue, Jun 25, 2019 at 11:40:25PM -0400, Sasha Levin wrote:
> From: Dave Jiang
>
> [ Upstream commit 7560cc3ca7d9d11555f80c830544e463fcdb28b8 ]
This commit was reverted upstream, please drop it from your stable
queue. It caused new lockdep issues.
Regards,
Joerg
On Tue, Jun 25, 2019 at 7:09 PM Will Deacon wrote:
>
> On Tue, Jun 25, 2019 at 12:34:56PM +0530, Vivek Gautam wrote:
> > On Mon, Jun 24, 2019 at 10:33 PM Will Deacon wrote:
> > > Instead, I think this needs to be part of a separate file that is
> > > maintained
> > > by you, which follows on
20 matches
Mail list logo
