On Thu, 2019-11-07 at 12:59 -0800, Deepa Dinamani wrote:
> The intel-iommu driver assumes that the iommu state is
> cleaned up at the start of the new kernel.
> But, when we try to kexec boot something other than the
> Linux kernel, the cleanup cannot be relied upon.
> Hence, cleanup before we go
On Thu, Nov 07, 2019 at 09:23:50PM +0800, zhangfei wrote:
> > What I had in mind is keep one uacce_mm per mm and per device, and we can
> > pass that to iommu_sva_bind_device(). It requires some structure changes,
> > see the attached patch.
> Cool, thanks Jean
> How about merge them together.
No
Hi,
On 11/8/19 5:27 AM, Deepa Dinamani wrote:
On Thu, Nov 7, 2019 at 12:59 PM Deepa Dinamani wrote:
+static void intel_iommu_shutdown(void)
+ if (no_iommu || dmar_disabled)
+ return;
This check is actually not required here, as the handler is only
installed after these
Hi,
On 11/8/19 4:59 AM, Deepa Dinamani wrote:
The intel-iommu driver assumes that the iommu state is
cleaned up at the start of the new kernel.
But, when we try to kexec boot something other than the
Linux kernel, the cleanup cannot be relied upon.
Hence, cleanup before we go down for reboot.
Hi Christoph,
On 11/7/19 5:34 PM, Christoph Hellwig wrote:
On Wed, Nov 06, 2019 at 01:11:30PM +0800, Lu Baolu wrote:
This adds a Kconfig option INTEL_IOMMU_SCALABLE_MODE_ON to make
it easier for distributions to enable or disable the Intel IOMMU
scalable mode during kernel build.
On Thu, 24 Oct 2019 08:26:23 -0400
Liu Yi L wrote:
> This patch adds vfio support to bind guest translation structure
> to host iommu. VFIO exposes iommu programming capability to user-
> space. Guest is a user-space application in host under KVM solution.
> For SVA usage in Virtual Machine,
On Wed, 6 Nov 2019 13:27:26 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, November 6, 2019 7:36 AM
> > To: Liu, Yi L
> > Subject: Re: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)
> >
> > On Thu, 24 Oct 2019 08:26:22 -0400
> > Liu Yi L wrote:
> >
On Thu, Nov 7, 2019 at 12:59 PM Deepa Dinamani wrote:
> +static void intel_iommu_shutdown(void)
> + if (no_iommu || dmar_disabled)
> + return;
This check is actually not required here, as the handler is only
installed after these have been checked in intel_iommu_init.
I can
The intel-iommu driver assumes that the iommu state is
cleaned up at the start of the new kernel.
But, when we try to kexec boot something other than the
Linux kernel, the cleanup cannot be relied upon.
Hence, cleanup before we go down for reboot.
Keeping the cleanup at initialization also, in
On Fri, Nov 01, 2019 at 08:18:49PM -0700, Max Filippov wrote:
> On Fri, Nov 1, 2019 at 3:02 PM Christoph Hellwig wrote:
> > this series switches over xtensa to use the generic DMA remap and
> > uncached code. Xtensa is a little special because it uses an uncached
> > segment by default, but can
These are pure cache maintainance routines, so drop the unused
struct device argument.
Signed-off-by: Christoph Hellwig
---
arch/arc/mm/dma.c | 8
arch/arm/mm/dma-mapping.c | 8
arch/arm/xen/mm.c | 12 ++--
Switch openrisc to use the dma-direct allocator and just provide the
hooks for setting memory uncached or cached.
Signed-off-by: Christoph Hellwig
---
arch/openrisc/Kconfig | 1 +
arch/openrisc/kernel/dma.c | 51 +-
2 files changed, 7 insertions(+), 45
We currently only support remapping memory as uncached through vmap
or a magic uncached segment provided by some architectures. But there
is a simpler and much better way available on some architectures where
we can just remap the memory in place. The advantages are:
1) no aliasing is
Hi all,
this series provides support for remapping places uncached in-place in
the generic dma-direct code, and moves openrisc over from its own
in-place remapping scheme. The arm64 folks also had interest in such
a scheme to avoid problems with speculating into cache aliases.
Also all
sta2x11 is the only x86 device that depends custom DMA direct functions.
It turns out it can be made standard by carefully setting the device's
DMA masks and offset.
Originally only patch #2 was sent but I realised patch #1 is also
needed, which is a good addition as it's also a prerequisite to
As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is
possible for a device configured with 32 bit DMA addresses and a partial
DMA mapping located at the end of the address space to overflow. It
happens when a higher physical address, not DMAable, is translated to
it's DMA
Hi Joerg,
Please pull these Arm SMMU updates for 5.5. The main changes are support
for the Qualcomm SMMUv2 implementation in the SDM845 SoC using the recently
introduced "implementation hook" code, a bunch of preparatory work to
expose TTBR1 via the io-pgtable code so that two (distinct) page
On 2019/11/6 下午11:32, Jean-Philippe Brucker wrote:
On Wed, Nov 06, 2019 at 04:17:40PM +0800, zhangfei wrote:
But I still believe it would be better to create an uacce_mm structure
that tracks all queues bound to this mm, and pass that to uacce_sva_exit
instead of the uacce_device.
I am
Hi Isaac,
On Mon, Nov 04, 2019 at 11:34:00AM -0800, Isaac J. Manjarres wrote:
> On Wed, Oct 30, 2019 at 02:51:12PM +, Will Deacon wrote:
> > diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
> > index 5c87a38620c4..2f82d40317d6 100644
> > ---
Hi Robin,
On 28.10.2019 15:42, Robin Murphy wrote:
> On 24/10/2019 13:41, Laurentiu Tudor wrote:
>> From: Laurentiu Tudor
>>
>> Introduce a few new dma unmap and sync variants that, on top of the
>> original variants, return the virtual address corresponding to the
>> input dma address.
>> In
On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC updates
4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
work with
On Wed, Nov 06, 2019 at 01:11:30PM +0800, Lu Baolu wrote:
> This adds a Kconfig option INTEL_IOMMU_SCALABLE_MODE_ON to make
> it easier for distributions to enable or disable the Intel IOMMU
> scalable mode during kernel build.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/Kconfig
On Wed, Nov 06, 2019 at 10:11:55PM -0800, Saravana Kannan wrote:
> > Right, in short the fundamental problem is that of_iommu_configure() now
> > does the wrong thing. Deferring probe of the entire host bridge/root
> > complex based on "iommu-map" would indeed happen to solve the problem by
> >
23 matches
Mail list logo
