On 2019/10/15 下午3:35, Christoph Hellwig wrote:
On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
From: Thiago Jung Bauermann
Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
be set by both device and guest driver. However, as a hack, when DMA API
returns
Currently hyperv-iommu is implemented in a x86 specific way, for
example, apic is used. So make the HYPERV_IOMMU Kconfig depend on X86
as a preparation for enabling HyperV on architecture other than x86.
Cc: Lan Tianyu
Cc: Michael Kelley
Cc: linux-hyp...@vger.kernel.org
Signed-off-by: Boqun
On Wed Oct 16 19, Jerry Snitselaar wrote:
On Wed Oct 16 19, Qian Cai wrote:
BTW, Joerg, this line from the commit "iommu/amd: Remove domain->updated" looks
suspicious. Not sure what the purpose of it.
*updated = increase_address_space(domain, gfp) || *updated;
Looking at it again I think
On Wed Oct 16 19, Qian Cai wrote:
After the commit 754265bcab78 ("iommu/amd: Fix race in
increase_address_space()"), it could still possible trigger a race
condition under some heavy memory pressure below. The race to trigger a
warning is,
CPU0: CPU1:
in alloc_pte():
After the commit 754265bcab78 ("iommu/amd: Fix race in
increase_address_space()"), it could still possible trigger a race
condition under some heavy memory pressure below. The race to trigger a
warning is,
CPU0: CPU1:
in alloc_pte(): in increase_address_space():
Hello Joerg Roedel,
The patch b911b89b6d01: "iommu/amd: Pass gfp-flags to
iommu_map_page()" from Jul 5, 2016, leads to the following static
checker warning:
drivers/iommu/amd_iommu.c:2545 amd_iommu_map()
warn: use 'gfp' here instead of GFP_XXX?
drivers/iommu/amd_iommu.c
2529
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: 78662bffde37ccbb66ac3311fa709d8960435e98
commit: 781ca2de89bae1b1d2c96df9ef33e9a324415995 [4470/4908] iommu: Add gfp
parameter to iommu_ops::map
reproduce:
# apt-get install sparse
# sparse
Fixes: 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map")
Signed-off-by: kbuild test robot
---
iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f8853dbf1c4eb..89bfdbbfaa11b 100644
---
On 10/16/2019 12:51 AM, Joerg Roedel wrote:
Hi,
On Tue, Oct 15, 2019 at 09:49:32AM -0700, Yian Chen wrote:
VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
for device use only and should not be part of allocable memory pool of OS.
BIOS e820_table reports complete memory
Hi Yuri,
On Tue, Oct 15, 2019 at 05:11:11PM +0200, Yuri Volchkov wrote:
> Currently dmar_fault handler only prints a message in the dmesg. This
> commit introduces counters - how many faults have happened, and
> exposes them via sysfs. Each pci device will have an entry
> 'dmar_faults' reading
Since commit ece6e6f0218b ("iommu/dma-iommu: Split iommu_dma_map_msi_msg()
in two parts"), iommu_dma_prepare_msi() should no longer have to worry
about preempting itself, nor being called in atomic context at all. Thus
we can downgrade the IRQ-safe locking to a simple mutex to avoid angering
the
Hi Robin,
On 16/10/2019 17:09, Robin Murphy wrote:
On 16/10/2019 17:03, Joerg Roedel wrote:
On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
The x86 one might just be a mistake.
diff --git a/drivers/iommu/amd_iommu.c
On 16/10/2019 17:11, Qian Cai wrote:
On Wed, 2019-10-16 at 18:03 +0200, Joerg Roedel wrote:
On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
The x86 one might just be a mistake.
diff --git a/drivers/iommu/amd_iommu.c
On Wed, 2019-10-16 at 18:03 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
> > On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> > The x86 one might just be a mistake.
> >
> > diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> >
On 16/10/2019 17:03, Joerg Roedel wrote:
On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
The x86 one might just be a mistake.
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index ad05484d0c80..63c4b894751d
On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
> On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> The x86 one might just be a mistake.
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index ad05484d0c80..63c4b894751d 100644
> ---
On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> Hi Qian,
>
> thanks for the report!
>
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> > > Today's linux-next generates a lot of warnings on multiple servers during
> > >
On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> BTW, the previous x86 warning was from only reverted one patch "iommu: Add gfp
> parameter to iommu_ops::map" where proved to be insufficient. Now, pasting the
> correct warning.
Can you please test this small fix:
diff --git
Hi Qian,
thanks for the report!
On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> > Today's linux-next generates a lot of warnings on multiple servers during
> > boot
> > due to the series "iommu/amd: Convert the AMD iommu driver to
ping function called from invalid context at
mm/page_alloc.c:4692
[ 564.374447][ T6222] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid:
6222, name: git
[ 564.382969][ T6222] INFO: lockdep is turned off.
[ 564.387644][ T6222] CPU: 25 PID: 6222 Comm: git Tainted:
GW 5.4.0-r
Tainted:
GW 5.4.0-rc3-next-20191016+ #7
[ 257.818035][ T6184] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 07/10/2019
[ 257.827313][ T6184] Call Trace:
[ 257.830487][ T6184] dump_stack+0x86/0xca
[ 257.834530][ T6184] ___might_sleep.cold.92+0xd2/0x122
[
On Wed, Sep 18, 2019 at 04:37:38PM +0100, Will Deacon wrote:
> On Thu, Aug 29, 2019 at 01:17:48PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Implement a generic function for removing reserved regions. This can be
> > used by drivers that don't do anything fancy with these
Hi Robin,
Two significant concerns right off the bat:
- It seems more common than not for silicon designers to fail to
implement IIDR correctly, so it's only a matter of time before
inevitably needing to bring back some firmware-level identifier
abstraction (if not already - does Hi161x have
From: Navneet Kumar
Use PTB_ASID instead of SMMU_CONFIG to flush smmu.
PTB_ASID can be accessed from non-secure mode, SMMU_CONFIG cannot be.
Using SMMU_CONFIG could pose a problem when kernel doesn't have secure
mode access enabled from boot.
Signed-off-by: Navneet Kumar
Reviewed-by: Dmitry
From: Thierry Reding
Page tables that reside in physical memory beyond the 4 GiB boundary are
currently not working properly. The reason is that when the physical
address for page directory entries is read, it gets truncated at 32 bits
and can cause crashes when passing that address to the DMA
From: Navneet Kumar
Enable clients' translation only after setting up the swgroups.
Signed-off-by: Navneet Kumar
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-smmu.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git
On 2019-10-16 9:47 am, John Garry wrote:
On 15/10/2019 19:00, Robin Murphy wrote:
Hi John,
On 30/09/2019 15:33, John Garry wrote:
This patchset adds IMP DEF event support for the SMMUv3 PMCG.
It is marked as an RFC as the method to identify the PMCG implementation
may be a quite disliked.
Hi Nathan,
On Mon, Oct 14, 2019 at 7:55 AM Nathan Chancellor
wrote:
>
> On Sat, Oct 12, 2019 at 05:59:18PM +0530, Shyam Saini wrote:
> > This parameters are not changed after early boot.
> > By making them __ro_after_init will reduce any attack surface in the
> > kernel.
> >
> > Link:
On 15/10/2019 19:00, Robin Murphy wrote:
Hi John,
On 30/09/2019 15:33, John Garry wrote:
This patchset adds IMP DEF event support for the SMMUv3 PMCG.
It is marked as an RFC as the method to identify the PMCG implementation
may be a quite disliked. And, in general, the series is somewhat
On Tue, Oct 15, 2019 at 09:35:01AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
> > From: Thiago Jung Bauermann
> >
> > Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
> > be set by both device and guest driver. However, as
Hi,
On Tue, Oct 15, 2019 at 09:49:32AM -0700, Yian Chen wrote:
> VT-d RMRR (Reserved Memory Region Reporting) regions are reserved
> for device use only and should not be part of allocable memory pool of OS.
>
> BIOS e820_table reports complete memory map to OS, including OS usable
> memory
On Wed, Oct 02, 2019 at 02:29:23PM -0300, Ezequiel Garcia wrote:
> IOMMU domain resource life is well-defined, managed
> by .domain_alloc and .domain_free.
>
> Therefore, domain-specific resources shouldn't be tied to
> the device life, but instead to its domain.
>
> Signed-off-by: Ezequiel
On Tue, Oct 15, 2019 at 2:10 PM Yoshihiro Shimoda
wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> This patch adds helper functions ipmmu_utlb_reg() and
> ipmmu_imu{asid,ctr}_write() for "uTLB" registers. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda
On Tue, Oct 15, 2019 at 2:10 PM Yoshihiro Shimoda
wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch uses ipmmu_features values instead of a macro to
> calculate context registers offset. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda
On Tue, Oct 15, 2019 at 2:10 PM Yoshihiro Shimoda
wrote:
> Since we will have changed memory mapping of the IPMMU in the future,
> This patch adds helper functions ipmmu_ctx_{reg,read,write}()
> for MMU "context" registers. No behavior change.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by:
35 matches
Mail list logo
