This patch series aims to implement VFIO support for platform devices that
reside behind an IOMMU. Examples of such devices are devices behind an ARM
SMMU, or behind a Samsung Exynos System MMU.
The API used is based on the existing VFIO API that is also used with PCI
devices. Only devices that in
This patch forms the common skeleton code for platform devices support
with VFIO. This will include the core functionality of VFIO_PLATFORM,
however binding to the device and discovering the device resources will
be done with the help of a separate file where any Linux platform bus
specific code wi
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform.c | 103 ++
include/uapi/linux/vfio.h | 1 +
2 file
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig | 9 +
drivers/vfio/platform/Makefile | 4
4 f
VFIO returns a file descriptor which we can use to manipulate the memory
regions of the device. Usually, the user will mmap memory regions that are
addressable on page boundaries, however for memory regions where this is
not the case we cannot provide mmap functionality due to security concerns.
Fo
This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
which allows the user to learn about the available MMIO resources of
a device.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 106 +-
drivers/vfio/platform/vfio_plat
A VFIO userspace driver will start by opening the VFIO device
that corresponds to an IOMMU group, and will use the ioctl interface
to get the basic device info, such as number of memory regions and
interrupts, and their properties. This patch enables the
VFIO_DEVICE_GET_INFO ioctl call.
Signed-off
Enable building the VFIO AMBA driver. VFIO_AMBA depends on VFIO_PLATFORM,
since it is sharing a portion of the code, and it is essentially implemented
as a platform device whose resources are discovered via AMBA specific APIs
in the kernel.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platfo
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_amba.c | 115 ++
include/uapi/linux/vfio.h | 1 +
2 files changed, 116 insertions(+
Allow to memory map the MMIO regions of the device so userspace can
directly access them. PIO regions are not being handled at this point.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 65
1 file changed, 65 insertions(+)
diff --
Return information for the interrupts exposed by the device.
This patch extends VFIO_DEVICE_GET_INFO with the number of IRQs
and enables VFIO_DEVICE_GET_IRQ_INFO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/Makefile| 2 +-
drivers/vfio/platform/vfio_platform_common
We want to reuse virqfd functionality in multiple VFIO drivers; before
moving these functions to core VFIO, add the vfio_ prefix to the
virqfd_enable and virqfd_disable functions, and export them so they can
be used from other modules.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pc
The Virqfd code needs to keep accesses to any struct *virqfd safe, but
this comes into play only when creating or destroying eventfds, so sharing
the same spinlock with the VFIO bus driver is not necessary.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci_intrs.c | 31 ++
VFIO_PCI passes the VFIO device structure *vdev via eventfd to the handler
that implements masking/unmasking of IRQs via an eventfd. We can replace
it in the virqfd infrastructure with an opaque type so we can make use
of the mechanism from other VFIO bus drivers.
Signed-off-by: Antonios Motakis
The functions vfio_pci_virqfd_init and vfio_pci_virqfd_exit are not really
PCI specific, since we plan to reuse the virqfd code with more VFIO drivers
in addition to VFIO_PCI.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci.c | 6 +++---
drivers/vfio/pci/vfio_pci_intrs.c | 4
This patch allows to set an eventfd for a platform device's interrupt,
and also to trigger the interrupt eventfd from userspace for testing.
Level sensitive interrupts are marked as maskable and are handled in
a later patch. Edge triggered interrupts are not advertised as maskable
and are implement
Level sensitive interrupts are exposed as maskable and automasked
interrupts and are masked and disabled automatically when they fire.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 99 ++-
drivers/vfio/platform/vfio_platform_private.h
The virqfd functionality that is used by VFIO_PCI to implement interrupt
masking and unmasking via an eventfd, is generic enough and can be reused
by another driver. Move it to a separate file in order to allow the code
to be shared.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/Makefile
This patch is a skeleton for the VFIO_DEVICE_SET_IRQS IOCTL, around which
most IRQ functionality is implemented in VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 52 +--
drivers/vfio/platform/vfio_platform_irq.c | 59
With this patch the VFIO user will be able to set an eventfd that can be
used in order to mask and unmask IRQs of platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 47 ---
drivers/vfio/platform/vfio_platform_private.h |
Now we have finally completely decoupled virqfd from VFIO_PCI. We can
initialize it from the VFIO generic code, in order to safely use it from
multiple independent VFIO bus drivers.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Makefile | 4 +++-
drivers/vfio/pci/Makefile | 3 +--
dri
Hi Mitch,
On Tue, Dec 23, 2014 at 05:39:22PM +, Mitchel Humpherys wrote:
> Currently we do a STLBIALL when we initialize the SMMU. However, in
> some configurations that register is not supposed to be touched and is
> marked as "Secure only" in the spec. Rip it out.
>
> Signed-off-by: Mitch
On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon wrote:
>> /* Invalidate the TLB, just in case */
>> -writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
>> writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
>> writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH);
>
> I was
On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys
wrote:
> On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon wrote:
>>> /* Invalidate the TLB, just in case */
>>> -writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
>>> writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
>>> wr
On Tue, Jan 06 2015 at 02:35:28 PM, Rob Herring wrote:
> On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys
> wrote:
>> On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon wrote:
/* Invalidate the TLB, just in case */
-writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with these faults:
dmar: DRHD: handling fault status reg 102
dmar: DMAR:[DMA Read] Reque
Allow specification of the domain-id for the new domain.
This patch only adds the 'did' parameter to iommu_attach_domain()
and modifies all of its callers to specify the default value of -1
which says "no did specified, allocate a new one".
This is no functional change from current behaviour -- ju
Interfaces for when a new domain in the crashdump kernel needs some
values from the panicked kernel's context entries.
Signed-off-by: Bill Sumner
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c | 62 +
1 file changed, 62 insertions(+)
dif
Add structure type domain_values_entry used for kdump;
Add context entry functions needed for kdump.
Bill Sumner:
Original version;
Li, Zhenhua:
Changed the name of new functions, make them consistent with current
context get/set functions.
Signed-off-by: Bill Sumner
Signed-off-by:
When a device driver issues the first dma_map command for a
device, we assign a new and empty page-table, thus removing all
mappings from the old kernel for the device.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c | 56 ++---
1 file changed,
Populate it with support functions to copy iommu translation tables from
from the panicked kernel into the kdump kernel in the event of a crash.
Functions:
malloc new context table and copy old context table to the new one.
malloc new page table and copy old page table to the new one.
Bil
Fix the intr-remapping fault.
[1.594890] dmar: DRHD: handling fault status reg 2
[1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d
[1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry
is clear
Use old irte in kdump kernel, do not disable and re-enable interr
Add some functions to copy the data from old kernel.
These functions are used to copy context tables and page tables.
To avoid calling iounmap between spin_lock_irqsave and spin_unlock_irqrestore,
use a link here, store the pointers , and then use iounmap to free them in
another place.
Li, Zhen-h
Functions to copy the irte data from the old kernel into the kdump kernel.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel_irq_remapping.c | 62 +
include/linux/intel-iommu.h | 4 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/iommu/i
Modify the operation of the following functions when called during crash dump:
device_to_domain_id
get_domain_for_dev
init_dmars
intel_iommu_init
Bill Sumner:
Original version.
Zhenhua:
Minor change,
The name of new calling functions.
Do not disable and re-enable T
Add functions to load root entry table from old kernel, and to save updated
root entry table.
Add two member in struct intel_iommu, to store the RTA in old kernel, and
the mapped virt address of it.
We use the old RTA in dump kernel, and when the iommu->root_entry is used as
a cache in kdump kerne
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1. Fixes a dump on Takao's system.
2. Reduces the count of faults on Baoquan's system.
Regards
Zhenhua
On
On 01/07/15 at 12:11pm, Li, ZhenHua wrote:
> Many thanks to Takao Indoh and Baoquan He, for your testing on more
> different systems.
>
> The calling of flush functions are added to this version.
>
> The usage of __iommu_flush_cache function :
> 1. Fixes a dump on Takao's system.
> 2. Reduces the
It is same as the last one I send to you yesterday.
The continuous memory that needed for data in this patchset:
RE: PAGE_SIZE, 4096 Bytes;
IRTE: 65536 * 16 ; 1M Bytes;
It should use same memory as the old versions of this patchset. The
changes for the last version do not need more memory.
Re
From: Thomas Gleixner
The whole iommu setup for irq remapping is a convoluted mess. The
iommu detect function gets called from mem_init() and the prepare
callback gets called from enable_IR_x2apic() for unknown reasons.
Of course AMD and Intel setup differs in nonsensical ways. Intels
prepare ca
Local variable x2apic_enabled has been assigned to but never referred,
so kill it.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/apic.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 8b58e23bc5e8..a614
When converting x86 to new hierarchy irqdoamin framework, Thomas noticed
that the interrupt remapping initialization flow is a little complex and
has troubles in memory allocation. Then there is a joint force to
simplify IR initialization flow, please refer to related threads at:
https://lkml.org/l
From: Thomas Gleixner
enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
installs the intel dmar remapping ops and then calls the amd iommu irq
remapping prepare callback to figure out whether we are running on an
AMD machine with irq remapping hardware.
Right after that it call
From: Thomas Gleixner
No reason anymore to do GFP_ATOMIC allocations which are not harmful
in the normal bootup case, but matter in the physical hotplug
scenario.
Signed-off-by: Thomas Gleixner
Tested-by: Borislav Petkov
Acked-by: Joerg Roedel
Cc: Jiang Liu
Cc: x...@kernel.org
Link: http://l
X2APIC will be disabled if user specifies "nox2apic" on kernel command
line, even when x2apic_preenabled is true. So correctly detect X2APIC
status by using x2apic_enabled() instead of x2apic_preenabled.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/apic.c |2 +-
1 file changed, 1 insert
Prepare for killing function irq_remapping_supported() by moving code
from intel_irq_remapping_supported() into intel_prepare_irq_remapping().
Combined with patch from Joerg at https://lkml.org/lkml/2014/12/15/487,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg
When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system
may panic or hang without useful messages. On the other hand, it's
hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled.
So panic with a clear message in such a case.
System panics as below when X2APIC is disab
Currently if CPU supports X2APIC, IR hardware must work in X2APIC mode
or disabled. Change the code to support IR working in XAPIC mode when
CPU supports X2APIC. Then the CPU APIC driver will decide how to handle
such as configuration by:
1) Disabling X2APIC mode
2) Forcing X2APIC physical mode
Th
From: Joerg Roedel
IRQ remapping is only supported when all IOMMUs in the
system support it. So check if all IOMMUs in the system
support IRQ remapping before doing the allocations.
[Jiang]
1) Rebased onto v3.19.
2) Remove redundant check of ecap_ir_support(iommu->ecap) in function
intel_enab
Refine enable_IR_x2apic() and related functions for better readability.
It also changes the way to handle IR in XAPIC mode when enabling X2APIC.
Previously it just skips X2APIC initialization without checking max CPU
APIC ID in system, which may cause problem if system has CPU with APIC
ID bigger
Simplify irq_remapping code by killing irq_remapping_supported() and
related interfaces.
Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h |
Change variable disable_irq_remap to be static and simplify the code.
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu_init.c |6 +-
drivers/iommu/intel_irq_remapping.c |5 -
drivers/iommu/irq_remapping.c |3 +--
drivers/iommu/irq_remapping.h |2 --
4
From: Joerg Roedel
This allows to get rid of the irq_remapping_supported()
function and all its call-backs into the Intel and AMD
IOMMU drivers.
Signed-off-by: Joerg Roedel
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu_init.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/dr
Refine code by normailizing the way to detect whether IR is enabled.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remappi
Assign intel_irq_remap_ops to remap_ops only if
intel_irq_remap_ops.prepare() succeeds.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode
will be disabled if:
1) Maximum CPU APIC ID is bigger than 255
2) hypervisior doesn't support x2apic mode.
But we should only check whether hypervisor supports X2APIC mode when
hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled, other
56 matches
Mail list logo
