>The two conditions can go into one if statement to make this a little
>more clear.
Ah, yeah of course
>And I'd really like to understand the unlikely - amd_iommu_np_cache
>is set based on a hardware capability, so it seems rather odd to mark
>it unlikely. Dynamic branch prediction really should
I'd be happy to offload all of the mentioned tasks to you if you
volunteer.
I think the first step is to move the two USB controller that can only
DMA to their own BAR off the existing DMA coherent infrastructure. The
controllers are already identified using the HCD_LOCAL_MEM flag, so we
just
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index efaea1a0a..ae476fe8d
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/pci/msi.c| 6 +++---
drivers/pci/search.c | 10 +++---
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 73986825d..e039b740f 100644
In several places in the kernel we find PCI_DEVID used like this:
PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper
for it.
Signed-off-by: Heiner Kallweit
---
include/linux/pci.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
In several places in the kernel we find PCI_DEVID used like this:
PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper
for it.
v2:
- apply the change to all affected places in the kernel
Heiner Kallweit (9):
PCI: add helper pci_dev_id
PCI: use helper pci_dev_id
r8169: use new
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
arch/powerpc/platforms/powernv/npu-dma.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f467cc4b4..5cb201422 100644
---
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/iommu/intel-iommu.c | 2 +-
drivers/iommu/intel_irq_remapping.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/platform/chrome/chromeos_laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/chromeos_laptop.c
b/drivers/platform/chrome/chromeos_laptop.c
index
I can see two potential problems with these patches that should be addressed:
The default domain of a group can be changed to type
IOMMU_DOMAIN_IDENTITY via the command line. With these patches we are
returning the si_domain for type IOMMU_DOMAIN_IDENTITY. There's a
chance the shared si_domain
On Wed, Apr 24, 2019 at 05:24:37PM +0300, Dan Carpenter wrote:
> We already dereferenced "dev" when we called get_dma_ops() so this NULL
> check is too late. We're not supposed to pass NULL "dev" pointers to
> dma_alloc_attrs().
Thanks, applied to the dma-mapping for-next tree.
> Signed-off-by:
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
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
As of commit 7af9a5fdb9e0ca33 ("iommu/ipmmu-vmsa: Use
iommu_device_sysfs_add()/remove()"), IOMMU devices show up under
/sys/class/iommu/, 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
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
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
Reviewed-by: Simon Horman
---
Apart from this, the driver doesn't support
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
On Wed, Apr 24, 2019 at 03:47:39PM +0100, Tom Murphy wrote:
> >And I'd really like to understand the unlikely - amd_iommu_np_cache
> >is set based on a hardware capability, so it seems rather odd to mark
> >it unlikely. Dynamic branch prediction really should do the right thing
> >here usually.
>
On Wed, Apr 24, 2019 at 05:06:38PM +0200, Christoph Hellwig wrote:
> I'd also use the oppurtunity to forbid a NULL dev argument and
> opencode those uses.
Actually, looking at your last patch again the NULL argument might
still fit in ok, so maybe we should keep it.
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
Reviewed-by: Simon Horman
---
v3:
- Add Reviewed-by,
v2:
- Add
check if there is a not-present cache present and flush it if there is.
Signed-off-by: Tom Murphy
---
drivers/iommu/amd_iommu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f7cdd2ab7f11..8ef43224aae0 100644
---
On Tue, Apr 23, 2019 at 03:32:16PM +0800, Lu Baolu wrote:
> When we add the bounce buffer between IOVA and physical buffer, the
> bounced buffer must starts from the same offset in a page, otherwise,
> IOMMU can't work here.
Why? Even with the odd hardware descriptors typical in Intel land that
On Wed, Apr 24, 2019 at 07:40:07AM -0300, Mauro Carvalho Chehab wrote:
> Personally, I don't care much with monospaced fonts on this table. After
> all, if I want to see it monospaced, I can simply click at the
> "View page source" at the browser, and it will display the file as a
> plain old
On Wed, Apr 24, 2019 at 07:58:19AM -0700, Christoph Hellwig wrote:
> I'd be tempted to do that. But lets just ask Joerg if he has
> any opinion..
The reason was that it is an unlikely path, as hardware implementations
are not allowed to set this bit. It is purely for emulated AMD IOMMUs.
I have
check if there is a not-present cache present and flush it if there is.
Signed-off-by: Tom Murphy
---
drivers/iommu/amd_iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f7cdd2ab7f11..91fe5cb10f50 100644
---
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> From: Lu Baolu
>
> If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
> IOMMU driver should rely on the emulation software to allocate
> and free PASID IDs.
Do we make the decision depending on the CM or depending on the VCCAP_REG?
Em Wed, 24 Apr 2019 16:54:10 +0200
Borislav Petkov escreveu:
> On Wed, Apr 24, 2019 at 07:40:07AM -0300, Mauro Carvalho Chehab wrote:
> > Personally, I don't care much with monospaced fonts on this table. After
> > all, if I want to see it monospaced, I can simply click at the
> > "View page
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> When VT-d driver runs in the guest, PASID allocation must be
> performed via virtual command interface. This patch register a
registers
> custom IOASID allocator which takes precedence over the default
> IDR based allocator.
nit: s/IDR based// . It
Hi Jacob
On 4/24/19 1:31 AM, Jacob Pan wrote:
> Move domainer helper to header to be used by SVA code.
s/domainer/domain
>
> Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Eric
> ---
> drivers/iommu/intel-iommu.c | 6 --
> include/linux/intel-iommu.h | 6 ++
> 2 files changed, 6
On Wed, Apr 24, 2019 at 4:55 PM Joerg Roedel wrote:
>
> On Wed, Apr 24, 2019 at 07:58:19AM -0700, Christoph Hellwig wrote:
> > I'd be tempted to do that. But lets just ask Joerg if he has
> > any opinion..
>
> The reason was that it is an unlikely path, as hardware implementations
> are not
On 16/04/2019 11:14, Will Deacon wrote:
> On Mon, Apr 08, 2019 at 10:31:47AM +0800, Leizhen (ThunderTown) wrote:
>> On 2019/4/4 23:30, Will Deacon wrote:
>>> On Mon, Mar 18, 2019 at 09:12:41PM +0800, Zhen Lei wrote:
v1 --> v2:
1. Drop part2. Now, we only use the SMMUv3 hardware
On Tue, Apr 23, 2019 at 03:35:51PM +0800, Lu Baolu wrote:
> Hi,
>
> On 4/23/19 2:08 PM, Christoph Hellwig wrote:
> > > > Again, this and the option should not be in a specific iommu driver.
> > > >
> > >
> > > The option of whether bounce is ignored should be in the specific iommu
> > > driver.
On Wed, 24 Apr 2019, Peter Zijlstra wrote:
> On Thu, Apr 18, 2019 at 10:41:37AM +0200, Thomas Gleixner wrote:
> > There is only one caller of check_prev_add() which hands in a zeroed struct
> > stack trace and a function pointer to save_stack(). Inside check_prev_add()
> > the stack_trace struct
Hi Christoph,
On Wed, Apr 24, 2019 at 05:06:38PM +0200, Christoph Hellwig wrote:
> On Tue, Mar 26, 2019 at 04:01:27PM -0700, Nicolin Chen wrote:
> > page = dma_alloc_from_contiguous(dev, count, order, gfp & __GFP_NOWARN);
> > + if (!page)
> > + page = alloc_pages(gfp, order);
>
>
On Wed, Apr 24, 2019 at 11:33:11AM -0700, Nicolin Chen wrote:
> I feel it's similar to my previous set, which did most of these
> internally except the renaming part. But Catalin had a concern
> that some platforms might have limits on CMA range [1]. Will it
> be still okay to do the fallback
On Wed, Apr 24, 2019 at 09:26:52PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 24, 2019 at 11:33:11AM -0700, Nicolin Chen wrote:
> > I feel it's similar to my previous set, which did most of these
> > internally except the renaming part. But Catalin had a concern
> > that some platforms might
On Thu, Apr 18, 2019 at 10:41:38AM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces and storing the information is a small lockdep
> specific data structure.
>
Acked-by: Peter Zijlstra (Intel)
On Thu, Apr 18, 2019 at 10:41:37AM +0200, Thomas Gleixner wrote:
> There is only one caller of check_prev_add() which hands in a zeroed struct
> stack trace and a function pointer to save_stack(). Inside check_prev_add()
> the stack_trace struct is checked for being empty, which is always
> true.
Hi Tom,
On 4/25/19 7:47 AM, Tom Murphy wrote:
I can see two potential problems with these patches that should be addressed:
The default domain of a group can be changed to type
IOMMU_DOMAIN_IDENTITY via the command line. With these patches we are
returning the si_domain for type
Hi,
On 4/24/19 10:45 PM, Christoph Hellwig wrote:
On Tue, Apr 23, 2019 at 03:32:16PM +0800, Lu Baolu wrote:
When we add the bounce buffer between IOVA and physical buffer, the
bounced buffer must starts from the same offset in a page, otherwise,
IOMMU can't work here.
Why? Even with the odd
Michael S. Tsirkin writes:
> On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
>>
>> Michael S. Tsirkin writes:
>>
>> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote:
>> >>
>> >> Michael S. Tsirkin writes:
>> >>
>> >> > On Wed, Mar 20, 2019 at
On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote:
>
> Michael S. Tsirkin writes:
>
> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann
On Tue, Apr 23, 2019 at 11:38:16PM +0200, Borislav Petkov wrote:
> If that is all the changes it would need, then I guess that's ok. Btw,
> those rst-conversion patches don't really show what got changed. Dunno
> if git can even show that properly. I diffed the two files by hand to
> see what got
On Tue, Apr 23, 2019 at 04:31:06PM -0700, Jacob Pan wrote:
> The allocator doesn't really belong in drivers/iommu because some
> drivers would like to allocate PASIDs for devices that aren't managed by
> an IOMMU, using the same ID space as IOMMU. It doesn't really belong in
> drivers/pci either
On Tue, Apr 23, 2019 at 04:06:40PM -0600, Jonathan Corbet wrote:
> Remember that most of our docs are 99% RST even though they were written
> by people who had never even heard of RST. I really don't think it's a
> big deal - a far smaller cognitive load than trying to keep up with any
> given
Hi Joerg,
Please can you pull these ARM SMMU updates for 5.2? The highlight is ATS
support in the SMMUv3 driver from Jean-Philippe. I have collected the
appropriate Acks from the PCI and IORT sides.
There is a trivial conflict with your api-features branch due to the diff
context in
Em Tue, 23 Apr 2019 23:38:16 +0200
Borislav Petkov escreveu:
> On Tue, Apr 23, 2019 at 05:05:02PM -0300, Mauro Carvalho Chehab wrote:
> > That's my view about how that specific file would be after
> > converted to ReST:
> >
> >
> >
There is a case in which cap_perms and ecap_perms can be reallocated
by different modules. e.g. the vfio-mdev-pci sample driver. To secure
the initialization of cap_perms and ecap_perms, this patch adds an
atomic variable to track the user of cap/ecap_perms bits. First caller
of
This patch splits the non-module specific codes from original
drivers/vfio/pci/vfio_pci.c into a common.c under drivers/vfio/pci.
This is for potential code sharing. e.g. vfio-mdev-pci driver
Cc: Kevin Tian
Cc: Lu Baolu
Signed-off-by: Liu, Yi L
---
drivers/vfio/pci/Makefile |2
This patch adds sample driver named vfio-mdev-pci. It is to wrap
a PCI device as a mediated device. For a pci device, once bound
to vfio-mdev-pci driver, user space access of this device will
go through vfio mdev framework. The usage of the device follows
mdev management method. e.g. user should
This patchset aims to add a vfio-pci-like meta driver as a demo
user of the vfio changes introduced in "vfio/mdev: IOMMU aware
mediated device" patchset from Baolu Lu.
Previous RFC v1 has given two proposals and the discussion could
be found in following link. Per the comments, this patchset adds
54 matches
Mail list logo
