This allows the default behavior to be controlled by a kernel config
option instead of changing the commandline for the kernel to include
"iommu.passthrough=on" or "iommu=pt" on machines where this is desired.
Likewise, for machines where this config option is enabled, it can be
disabled at boot
On Fri, Jul 20, 2018 at 5:16 AM, Joerg Roedel wrote:
> Hi Olof,
>
> On Wed, Jul 11, 2018 at 01:59:35PM -0700, Olof Johansson wrote:
>> +config IOMMU_DEFAULT_PASSTHROUGH
>> + bool "IOMMU passthrough by default"
>> + depends on IOMMU_API
>> +help
>> + Enable passthrough by
When attaching a device to an IOMMU group with
CONFIG_DEBUG_ATOMIC_SLEEP=y:
BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 128, pid: 61, name: kworker/1:1
...
Call trace:
...
arm_lpae_alloc_pgtable+0x114/0x184
On Fri, Jul 13, 2018 at 11:27:56AM -0500, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> Add a clock to the SMMU node bindings.
>
> Signed-off-by: Thor Thayer
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.txt | 16
> 1 file changed, 16 insertions(+)
>
Hi Linus,
The following changes since commit 9d3cce1e8b8561fed5f383d22a4d6949db4eadbe:
Linux 4.18-rc5 (2018-07-15 12:49:31 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v4.18-rc5
for you to fetch changes up to
On Fri, 20 Jul 2018, Mathias Nyman wrote:
> >> But we need to fix this properly as well.
> >> xhci needs to be more in sync with usb core in usb_set_interface(),
> >> currently xhci
> >> has the altssetting up and running when usb core hasn't event started
> >> flushing endpoints.
> >
> >
On Fri, Jul 20, 2018 at 02:33:44PM +0200, Michal Simek wrote:
> Hi,
>
> On 19.7.2018 14:54, Christoph Hellwig wrote:
> > Hi Michal,
> >
> > can you review these patches to switch microblaze to use the generic
> > dma-noncoherent code? All the requirements are in mainline already
> > and we've
Hi Mathias,
On Fri, Jul 20, 2018 at 02:10:58PM +0300, Mathias Nyman wrote:
> On 19.07.2018 20:32, Sudip Mukherjee wrote:
> > Hi Mathias,
> >
> > On Thu, Jul 19, 2018 at 06:42:19PM +0300, Mathias Nyman wrote:
> > > > > As first aid I could try to implement checks that make sure the
> > > > >
On Sat, Jul 14, 2018 at 03:46:53PM +0800, Lu Baolu wrote:
> Lu Baolu (9):
> iommu/vt-d: Global PASID name space
> iommu/vt-d: Avoid using idr_for_each_entry()
> iommu/vt-d: Apply global PASID in SVA
> iommu/vt-d: Move device_domain_info to header
> iommu/vt-d: Add
On Fri, Jul 20, 2018 at 10:45:45AM +0200, Anna-Maria Gleixner wrote:
> The WARN_ON() was introduced in commit 272e4f99e966 ("iommu/amd: WARN
> when __[attach|detach]_device are called with irqs enabled") to ensure
> that the domain->lock is taken in proper irqs disabled context. This
> is
Hi,
On 19.7.2018 14:54, Christoph Hellwig wrote:
> Hi Michal,
>
> can you review these patches to switch microblaze to use the generic
> dma-noncoherent code? All the requirements are in mainline already
> and we've switched various architectures over to it already.
>
I can't see any issue
On Tue, Jul 17, 2018 at 06:07:07PM +0200, Paul Menzel wrote:
> On a MSI B350M MORTAR with AMD Ryzen 3 2200g (Raven) with Linux 4.18-rc5+
> and Debian Sid/unstable `pci_iommu_init` takes 40 ms according to
> `initcall_debug`.
40ms is a lot indeed, but IOMMU initialization is also a complex process
Hi Paul,
On Tue, Jul 17, 2018 at 06:02:07PM +0200, Paul Menzel wrote:
> $ dmesg
> […]
> [0.145696] calling pci_iommu_init+0x0/0x3f @ 1
> [0.145719] AMD-Vi: Unable to write to IOMMU perf counter.
This is likely a firmware issue. Either the IVRS ACPI table is incorrect
or the BIOS did not
Hi Olof,
On Wed, Jul 11, 2018 at 01:59:35PM -0700, Olof Johansson wrote:
> +config IOMMU_DEFAULT_PASSTHROUGH
> + bool "IOMMU passthrough by default"
> + depends on IOMMU_API
> +help
> + Enable passthrough by default (removing the need to pass in
> +
On Mon, Jul 09, 2018 at 11:53:31AM +0900, Yoshihiro Shimoda wrote:
> The TTSEL bit of IMUCTRn register of R-Car Gen3 needs to be set
> unused MMU context number even if uTLBs are disabled
> (The MMUEN bit of IMUCTRn register = 0).
> Since initial values of IMUCTRn.TTSEL on all IPMMU-domains are 0,
On Sun, Jul 08, 2018 at 02:23:21PM +0800, Lu Baolu wrote:
> This reverts commit ab96746aaa344fb720a198245a837e266fad3b62.
>
> The commit ab96746aaa34 ("iommu/vt-d: Clean up pasid quirk for
> pre-production devices") triggers ECS mode on some platforms
> which have broken ECS support. As the
On 19.07.2018 17:57, Alan Stern wrote:
On Thu, 19 Jul 2018, Mathias Nyman wrote:
xhci driver will set up all the endpoints for the new altsetting already in
usb_hcd_alloc_bandwidth().
New endpoints will be ready and rings running after this. I don't know the exact
history behind this, but I
On 19.07.2018 20:32, Sudip Mukherjee wrote:
Hi Mathias,
On Thu, Jul 19, 2018 at 06:42:19PM +0300, Mathias Nyman wrote:
As first aid I could try to implement checks that make sure the flushed URBs
trb pointers really are on the current endpoint ring, and also add some warning
if we are we are
On July 20, 2018 12:55:04 PM GMT+03:00, lijiang wrote:>
>Thanks for your advice, I will rewrite the log and send them again.
Do not send them again - explain the problem properly first!
--
Sent from a small device: formatting sux and brevity is inevitable.
在 2018年07月20日 15:32, Borislav Petkov 写道:
> On Fri, Jul 20, 2018 at 01:23:04PM +0800, Dave Young wrote:
>>> Here, it doesn't need to dump MMIO space of the previous kernel, when the
>>> kdump kernel boot, the MMIO address will be remapped in decryption manners,
>>> but the MMIO address don't belong
The WARN_ON() was introduced in commit 272e4f99e966 ("iommu/amd: WARN
when __[attach|detach]_device are called with irqs enabled") to ensure
that the domain->lock is taken in proper irqs disabled context. This
is required, because the domain->lock is taken as well in irq
context.
The proper
Hi Rob,
On Fri, Jul 20, 2018 at 4:38 AM, Rob Herring wrote:
> On Thu, Jul 19, 2018 at 11:54 AM Vivek Gautam
> wrote:
>>
>> Add device node for arm,mmu-500 available on sdm845.
>> This MMU-500 with single TCU and multiple TBU architecture
>> is shared among all the peripherals except gpu on
On Fri, Jul 20, 2018 at 01:23:04PM +0800, Dave Young wrote:
> > Here, it doesn't need to dump MMIO space of the previous kernel, when the
> > kdump kernel boot, the MMIO address will be remapped in decryption manners,
> > but the MMIO address don't belong to the range of the crash reserved memory,
23 matches
Mail list logo
