Hi Marc, Robin, Alex,
On 4/3/19 7:38 PM, Alex Williamson wrote:
> On Wed, 3 Apr 2019 16:30:15 +0200
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 3/22/19 11:09 PM, Alex Williamson wrote:
>>> On Fri, 22 Mar 2019 10:30:02 +0100
>>> Auger Eric wrote:
>>>
Hi Alex,
On 3/22/19 12:01 AM, Ale
Hi James,
I did a sanity test from my end. The test machine fails to boot. I
haven't seen any valuable kernel log. It results in a purple screen.
Best regards,
Lu Baolu
On 3/29/19 11:26 PM, James Sewart wrote:
Hey Lu,
I’ve attached a preliminary v3, if you could take a look and run some tests
On Wed, Apr 3, 2019 at 6:42 PM Tycho Andersen wrote:
>
> On Wed, Apr 03, 2019 at 05:12:56PM -0700, Andy Lutomirski wrote:
> > On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
> > >
> > > From: Tycho Andersen
> > >
> > > Oopsing might kill the task, via rewind_stack_do_exit() at the bottom, and
On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>
> XPFO flushes kernel space TLB entries for pages that are now mapped
> in userspace on not only the current CPU but also all other CPUs
> synchronously. Processes on each core allocating pages causes a
> flood of IPI messages to all other cores
On Wed, Apr 03, 2019 at 05:12:56PM -0700, Andy Lutomirski wrote:
> On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
> >
> > From: Tycho Andersen
> >
> > Oopsing might kill the task, via rewind_stack_do_exit() at the bottom, and
> > that might sleep:
> >
>
>
> > diff --git a/arch/x86/mm/fault.
On Thu, Mar 28, 2019 at 07:55:20AM +0200, Mike Rapoport wrote:
Hi,
On Wed, Mar 27, 2019 at 01:57:43PM -0400, Sasha Levin wrote:
From: Mike Rapoport
[ Upstream commit a0bf842e89a3842162aa8514b9bf4611c86fee10 ]
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates
On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>
> From: Tycho Andersen
>
> Oopsing might kill the task, via rewind_stack_do_exit() at the bottom, and
> that might sleep:
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 9d5c75f02295..7891add0913f 100644
> --- a/arch/x86/mm
From: Juerg Haefliger
This patch adds support for XPFO for x86-64. It uses the generic
infrastructure in place for XPFO and adds the architecture specific
bits to enable XPFO on x86-64.
CC: x...@kernel.org
Suggested-by: Vasileios P. Kemerlis
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho
From: Tycho Andersen
We need someting like this for testing XPFO. Since it's architecture
specific, putting it in the test code is slightly awkward, so let's make it
an arch-specific symbol and export it for use in LKDTM.
CC: linux-arm-ker...@lists.infradead.org
CC: x...@kernel.org
Signed-off-by
From: Tycho Andersen
vm_mmap is exported, which means kernel modules can use it. In particular,
for testing XPFO support, we want to use it with the MAP_HUGETLB flag, so
let's support it via vm_mmap.
Signed-off-by: Tycho Andersen
Tested-by: Marco Benatto
Tested-by: Khalid Aziz
Cc: Khalid Aziz
From: Juerg Haefliger
Enable support for eXclusive Page Frame Ownership (XPFO) for arm64 and
provide a hook for updating a single kernel page table entry (which is
required by the generic XPFO code).
XPFO doesn't support section/contiguous mappings yet, so let's disable
it if XPFO is turned on.
When XPFO forces a TLB flush on all cores, the performance impact is
very significant. Batching as many of these TLB updates as
possible can help lower this impact. When a userspace allocates a
page, kernel tries to get that page from the per-cpu free list.
This free list is replenished in bulk whe
From: Julian Stecklina
Only the xpfo_kunmap call that needs to actually unmap the page
needs to be serialized. We need to be careful to handle the case,
where after the atomic decrement of the mapcount, a xpfo_kmap
increased the mapcount again. In this case, we can safely skip
modifying the page
From: Tycho Andersen
In some cases (on arm64 DMA and data cache flushes) we may have unmapped
the underlying pages needed for something via XPFO. Here are some
primitives useful for ensuring the underlying memory is mapped/unmapped in
the face of xpfo.
Signed-off-by: Tycho Andersen
Signed-off-b
From: Juerg Haefliger
XPFO can unmap a bounce buffer. Check for this and map it back in if
needed.
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho Andersen
Signed-off-by: Khalid Aziz
Cc: Khalid Aziz
Reviewed-by: Konrad Rzeszutek Wilk
---
v9: * Added a generic check for whether a page is
From: Juerg Haefliger
If the page is unmapped by XPFO, a data cache flush results in a fatal
page fault, so let's temporarily map the region, flush the cache, and then
unmap it.
CC: linux-arm-ker...@lists.infradead.org
Signed-off-by: Juerg Haefliger
Signed-off-by: Tycho Andersen
---
v6: actual
From: Juerg Haefliger
This test simply reads from userspace memory via the kernel's linear
map.
v6: * drop an #ifdef, just let the test fail if XPFO is not supported
* add XPFO_SMP test to try and test the case when one CPU does an xpfo
unmap of an address, that it can't be used accide
XPFO flushes kernel space TLB entries for pages that are now mapped
in userspace on not only the current CPU but also all other CPUs
synchronously. Processes on each core allocating pages causes a
flood of IPI messages to all other cores to flush TLB entries.
Many of these messages are to flush the
From: Juerg Haefliger
This patch adds basic support infrastructure for XPFO which protects
against 'ret2dir' kernel attacks. The basic idea is to enforce exclusive
ownership of page frames by either the kernel or userspace, unless
explicitly requested by the kernel. Whenever a page destined for
u
This is another update to the work Juerg, Tycho and Julian have
done on XPFO. After the last round of updates, we were seeing very
significant performance penalties when stale TLB entries were
flushed actively after an XPFO TLB update. Benchmark for measuring
performance is kernel build using para
From: Tycho Andersen
Oopsing might kill the task, via rewind_stack_do_exit() at the bottom, and
that might sleep:
Aug 23 19:30:27 xpfo kernel: [ 38.302714] BUG: sleeping function called from
invalid context at ./include/linux/percpu-rwsem.h:33
Aug 23 19:30:27 xpfo kernel: [ 38.303837] in_at
On Wed, Apr 03, 2019 at 07:26:40PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> > We still have a few drivers which pass a NULL struct device pointer
> > to DMA API functions, which generally is a bad idea as the API
> > impleme
I think this might have been this commit:
commit 24132a419c68f1d69eb8ecc91b3c80d730ecbb59
Author: Christoph Hellwig
Date: Fri Feb 15 09:30:28 2019 +0100
sparc64/pci_sun4v: allow large DMA masks
the patch below adds a few missing checks and hopefully should fix
your problem. If not can yo
On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and vari
The maximum number of micro-TLBs per IPMMU instance is not fixed, but
depends on the SoC type. Hence move it from struct ipmmu_vmsa_device to
struct ipmmu_features, and set up the correct value for both R-Car Gen2
and Gen3 SoCs.
Note that currently no code uses this value.
Signed-off-by: Geert U
Make the IPMMU_CTX_MAX constant unsigned, to match the type of
ipmmu_features.number_of_contexts.
This allows to use plain min() instead of type-casting min_t().
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
v2:
- Add Reviewed-by.
---
drivers/iommu/ipmmu-vmsa.c | 5 ++--
Hi Jörg, Magnus,
On R-Car Gen3 systems with PSCI, PSCI may power down the SoC during
system suspend, thus losing all IOMMU state. Hence after s2ram, devices
behind an IPMMU (e.g. SATA), and configured to use it, will fail to
complete their I/O operations.
This patch series adds suspend/r
On R-Car Gen3, the faulting virtual address is a 40-bit address, and
comprised of two registers. Read the upper address part, and combine
both parts, when running on a 64-bit system.
Signed-off-by: Geert Uytterhoeven
---
Apart from this, the driver doesn't support 40-bit IOVA addresses yet.
v2:
ipmmu_domain_init_context() takes care of (1) initializing the software
domain, and (2) initializing the hardware context for the domain.
Extract the code to initialize the hardware context into a new subroutine
ipmmu_domain_setup_context(), to prepare for later reuse.
Signed-off-by: Geert Uytter
As of commit 7af9a5fdb9e0ca33 ("iommu/ipmmu-vmsa: Use
iommu_device_sysfs_add()/remove()"), IOMMU devices show up under
/sys/class/iommus/, but their "devices" subdirectories are empty.
Likewise, devices tied to an IOMMU do not have an "iommu" backlink.
Make sure all links are created, on both arm3
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and all
IPMMU state is lost. Hence after s2ram, devices wired behind an IPMMU,
and configured to use it, will see their DMA operations hang.
To fix this, restore all IPMMU contexts, and re-enable all active
micro-TLBs during system res
On Wed, 3 Apr 2019 16:30:15 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 3/22/19 11:09 PM, Alex Williamson wrote:
> > On Fri, 22 Mar 2019 10:30:02 +0100
> > Auger Eric wrote:
> >
> >> Hi Alex,
> >> On 3/22/19 12:01 AM, Alex Williamson wrote:
> >>> On Sun, 17 Mar 2019 18:22:19 +0100
> >>> Eric
On 02/04/2019 23:39, Rob Gardner wrote:
On 4/2/19 2:30 PM, Meelis Roos wrote:
[ 17.566584] scsi host0: ioc0: LSISAS1064 A3, FwRev=010ah,
Ports=1, MaxQ=511, IRQ=27
[ 17.595897] mptsas: ioc0: attaching ssp device: fw_channel 0,
fw_id 0, phy 0, sas_addr 0x5000c5001799a45d
[ 17.598465] U
On 03/21/2019 11:52 PM, Christoph Hellwig wrote:
> Just like we do for all other DMA operations.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
__
On 03/21/2019 11:52 PM, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
Any comments on the remaining patches? I'd like to give this series
a couple weeks of soaking in linux-next before the end of the merge
window, so reviews would be apprciated.
On Thu, Mar 21, 2019 at 03:52:28PM -0700, Christoph Hellwig wrote:
> We still have a few drivers which pass a NULL struct
Hi Alex,
On 3/22/19 11:09 PM, Alex Williamson wrote:
> On Fri, 22 Mar 2019 10:30:02 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>> On 3/22/19 12:01 AM, Alex Williamson wrote:
>>> On Sun, 17 Mar 2019 18:22:19 +0100
>>> Eric Auger wrote:
>>>
This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioct
03.04.2019 11:41, Thierry Reding пишет:
> On Thu, Mar 07, 2019 at 01:50:07AM +0300, Dmitry Osipenko wrote:
>> Both Tegra30 and Tegra114 have 4 ASID's and the corresponding bitfield of
>> the TLB_FLUSH register differs from later Tegra generations that have 128
>> ASID's.
>>
>> In a result the PTE's
On 4/2/2019 7:24 PM, Robin Murphy wrote:
On 30/03/2019 14:18, Vivek Gautam wrote:
You should probably have some "bus" and "iface" clocks too, per the
requirement of "qcom,smmu-v2". Maybe Vivek might know what's relevant
for MSM8998?
As Jeffrey rightly mentioned, these clocks are not under th
On 03/04/2019 09:14, Greg KH wrote:
On Wed, Apr 03, 2019 at 09:02:36AM +0100, John Garry wrote:
On 28/03/2019 10:08, John Garry wrote:
In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
devres release"), we changed the ordering of tearing down the device DMA
ops and releas
From: Jinyu Qi
In struct iova_domain, there are three atomic variables, the former two
are about TLB flush counters which use atomic_add operation, anoter is
used to flush timer that use cmpxhg operation.
These variables are in the same cache line, so it will cause some
performance loss under th
On Thu, Mar 07, 2019 at 01:50:09AM +0300, Dmitry Osipenko wrote:
> Set PTE read/write attributes accordingly to the the protections requested
> by IOMMU API.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/iommu/tegra-smmu.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(
On Thu, Mar 07, 2019 at 01:50:08AM +0300, Dmitry Osipenko wrote:
> Release all memory allocations associated with a released domain and emit
> warning if domain is in-use at the time of destruction.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/iommu/tegra-smmu.c | 3 +++
> 1 file changed,
On Thu, Mar 07, 2019 at 01:50:07AM +0300, Dmitry Osipenko wrote:
> Both Tegra30 and Tegra114 have 4 ASID's and the corresponding bitfield of
> the TLB_FLUSH register differs from later Tegra generations that have 128
> ASID's.
>
> In a result the PTE's are now flushed correctly from TLB and this f
On Wed, Apr 03, 2019 at 09:02:36AM +0100, John Garry wrote:
> On 28/03/2019 10:08, John Garry wrote:
> > In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
> > devres release"), we changed the ordering of tearing down the device DMA
> > ops and releasing all the device's resou
On 28/03/2019 10:08, John Garry wrote:
In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
devres release"), we changed the ordering of tearing down the device DMA
ops and releasing all the device's resources; this was because the DMA ops
should be maintained until we release
46 matches
Mail list logo
