If IRTE is in posted format, the 'pda' field goes across the 64-bit
boundary, we need use cmpxchg16b to atomically update it. We only
expose posted-interrupt when X86_FEATURE_CX16 is supported and use
to update it atomically.
Signed-off-by: Feng Wu
---
drivers/iommu/intel_irq_remapping.c | 33 ++
> -Original Message-
> From: David Matlack [mailto:dmatl...@google.com]
> Sent: Thursday, October 15, 2015 7:41 AM
> To: Wu, Feng
> Cc: Paolo Bonzini ; alex.william...@redhat.com; Joerg
> Roedel ; Marcelo Tosatti ;
> eric.au...@linaro.org; kvm list ; iommu@lists.linux-
> foundation.org;
I don't think I'm explicitly trying to attach to that PCI bus. As far as my
limited understanding goes, I've got a vanilla virtualization
configuration, where I'm running some virtio and pv drivers, but they're
not attaching directly to any specific bus or device.
I'll gladly try this patch - it'l
There is really no way to safely give a user full access to a DMA
capable device without an IOMMU to protect the host system. There is
also no way to provide DMA translation, for use cases such as device
assignment to virtual machines. However, there are still those users
that want userspace driv
On Tue, 2015-10-13 at 22:34 +0100, David Woodhouse wrote:
> If the device itself reports ATS in its PCIe capabilities, but the BIOS
> neglects to provide an ATSR structure to indicate that the root port can
> also cope, then assume the latter is lying.
Except, of course, that integrated devices ar
On 14/10/15 12:50, j...@8bytes.org wrote:
Hi Robin,
On Tue, Oct 13, 2015 at 01:12:46PM +0100, Robin Murphy wrote:
Anyway, what are your thoughts on taking this for 4.4? Since the
dependencies are now in and we're at -rc5 already, I'm on the verge
of reposting a self-contained version to go thro
On 2015-10-14 04:10, Joerg Roedel wrote:
Hi Jay,
On Tue, Oct 13, 2015 at 04:52:43AM -0500, Jay Cornwall wrote:
handle_mm_fault indirectly triggers a BUG in do_numa_page when given
a VMA without read/write/execute access. Check this condition in
do_fault.
do_fault -> handle_mm_fault -> handle
On 14/10/15 14:35, Catalin Marinas wrote:
On Thu, Oct 01, 2015 at 08:13:59PM +0100, Robin Murphy wrote:
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Since there is still work to do elsewhere to make DMA co
On Wed, Oct 14, 2015 at 09:05:05AM -0700, G. Richard Bellamy wrote:
> When I have "iommu=1 iommu=pt amd_iommu_dump=1" on my Kernel command line, the
> messages spam the log so much neither dmesg nor the journal can keep up.
Hmm, the ACPI table looks good, which device(s) are you attaching to the
g
On Thu, Oct 01, 2015 at 08:13:59PM +0100, Robin Murphy wrote:
> Taking some inspiration from the arch/arm code, implement the
> arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
>
> Since there is still work to do elsewhere to make DMA configuration happen
> in a more approp
On Wed, 2015-10-14 at 13:19 +0200, Joerg Roedel wrote:
> On Tue, Oct 13, 2015 at 05:18:29PM +0200, Jinpu Wang wrote:
> > > and during search I found a patch from Christian:
> > > http://permalink.gmane.org/gmane.linux.kernel.iommu/9993
>
> I think David alreadt applied this patch.
However, in doi
On Wed, Oct 14, 2015 at 1:19 PM, Joerg Roedel wrote:
> On Tue, Oct 13, 2015 at 05:18:29PM +0200, Jinpu Wang wrote:
>> > and during search I found a patch from Christian:
>> > http://permalink.gmane.org/gmane.linux.kernel.iommu/9993
>
> I think David alreadt applied this patch.
>
Yes, thanks Joerg
On Fri, Oct 09, 2015 at 10:23:02AM +0800, Yong Wu wrote:
> Yong Wu (6):
> dt-bindings: iommu: Add binding for mediatek IOMMU
> dt-bindings: mediatek: Add smi dts binding
> iommu: add ARM short descriptor page table allocator
> memory: mediatek: Add SMI driver
> iommu/mediatek: Add mt8173
On Fri, Oct 09, 2015 at 10:23:05AM +0800, Yong Wu wrote:
> This patch is for ARM Short Descriptor Format.
>
> Signed-off-by: Yong Wu
I think it would be good if Will Deacon could have a look on that.
Will, any comments on this patch?
Joerg
__
On Fri, Oct 09, 2015 at 10:23:07AM +0800, Yong Wu wrote:
> + /*
> + * There is a domain for each a iommu device in normal case.
> + * But MTK only has one iommu domain called the m4u domain which all
> + * the multimedia HW share. Here we reserve one as the m4u domain and
> +
On Fri, Oct 02, 2015 at 06:02:42PM -0500, Suman Anna wrote:
> Suman Anna (2):
> Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs
> iommu/omap: Add support for configuring dsp iommus on DRA7xx
>
> .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++
> drivers/iommu/om
On Thu, Oct 08, 2015 at 03:45:47PM +0800, Chen Feng wrote:
> +static int hi6220_smmu_attach_dev(struct iommu_domain *domain,
> + struct device *dev)
> +{
> + struct hi6220_domain *m_domain = to_hi6220_domain(domain);
> +
> + smmu_domain_prepare(m_domain);
> +
Hi Robin,
On Tue, Oct 13, 2015 at 01:12:46PM +0100, Robin Murphy wrote:
> Anyway, what are your thoughts on taking this for 4.4? Since the
> dependencies are now in and we're at -rc5 already, I'm on the verge
> of reposting a self-contained version to go through arm64, as we
> really need to unblo
On Thu, Oct 01, 2015 at 08:13:59PM +0100, Robin Murphy wrote:
> Taking some inspiration from the arch/arm code, implement the
> arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
>
> Since there is still work to do elsewhere to make DMA configuration happen
> in a more approp
On Tue, Oct 13, 2015 at 05:18:29PM +0200, Jinpu Wang wrote:
> > and during search I found a patch from Christian:
> > http://permalink.gmane.org/gmane.linux.kernel.iommu/9993
I think David alreadt applied this patch.
___
iommu mailing list
iommu@lists.l
Hi Jay,
On Tue, Oct 13, 2015 at 04:52:43AM -0500, Jay Cornwall wrote:
> handle_mm_fault indirectly triggers a BUG in do_numa_page when given
> a VMA without read/write/execute access. Check this condition in do_fault.
>
> do_fault -> handle_mm_fault -> handle_pte_fault -> do_numa_page
>
> mm/m
On Sat, Oct 03, 2015 at 05:19:25PM -0700, G. Richard Bellamy wrote:
> What happens: Kernel logs message to journal, kvm VMs no longer work. Kernel
> messages spew at a rate of ~660/sec.
The problem is that device 00:14.0 is trying to write to the system
management area and is forbidden to do so b
22 matches
Mail list logo