On Fri, 17 Nov 2017 14:51:52 -0700
Alex Williamson wrote:
> On Fri, 17 Nov 2017 15:11:19 -0600
> Suravee Suthikulpanit wrote:
>
> > From: Suravee Suthikulpanit
> >
> > VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires
> > IOTLB flushing for every unmapping. This resul
On 11/17/2017 3:11 PM, Suravee Suthikulpanit wrote:
From: Suravee Suthikulpanit
Implement the newly added IOTLB flushing interface by introducing
per-protection-domain IOTLB flush list, which maintains a list of
IOVAs to be invalidated (by INVALIDATE_IOTLB_PAGES command) during
IOTLB sync.
Cc:
On Fri, 17 Nov 2017 15:11:19 -0600
Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit
>
> VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires
> IOTLB flushing for every unmapping. This results in large IOTLB flushing
> overhead when handling pass-through devices w
From: Suravee Suthikulpanit
VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires
IOTLB flushing for every unmapping. This results in large IOTLB flushing
overhead when handling pass-through devices with a large number of mapped
IOVAs (e.g. GPUs).
This can be avoided by usin
From: Suravee Suthikulpanit
Currently, when pass-through dGPU to a guest VM, there are thousands
of IOTLB flush commands sent from IOMMU to end-point-device. This cause
performance issue when launching new VMs, and could cause IOTLB invalidate
time-out issue on certain dGPUs.
This can be avoided
From: Suravee Suthikulpanit
Implement the newly added IOTLB flushing interface by introducing
per-protection-domain IOTLB flush list, which maintains a list of
IOVAs to be invalidated (by INVALIDATE_IOTLB_PAGES command) during
IOTLB sync.
Cc: Joerg Roedel
Signed-off-by: Suravee Suthikulpanit
-
Currently, when device DMA faults are detected by IOMMU the fault
reasons are printed but the driver of the offending device is
involved in fault handling.
This patch uses per device fault reporting API to send fault event
data for further processing.
Offending device is identified by the source ID
With the introduction of generic IOMMU device fault reporting API, we
can replace the private fault callback functions with standard function
and event data.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-svm.c | 7 +--
include/linux/intel-svm.h | 20 +++-
2 files changed,
Currently, dmar fault IRQ handler does nothing more than rate
limited printk, no critical hardware handling need to be done
in IRQ context.
Convert it to threaded IRQ would allow fault processing that
requires process context. e.g. find out offending device based
on source ID in the fault rasons.
Device faults detected by IOMMU can be reported outside IOMMU
subsystem for further processing. This patch intends to provide
a generic device fault data such that device drivers can be
communicated with IOMMU faults without model specific knowledge.
The proposed format is the result of discussion
This patch adds page response support for Intel VT-d.
Generic response data is taken from the IOMMU API
then parsed into VT-d specific response descriptor format.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 30 ++
1 file changed, 30 insertions(+)
diff
If the source device of a page request has its PASID table pointer
bond to a guest, the first level page tables are owned by the guest.
In this case, we shall let guest OS to manage page fault.
This patch uses the IOMMU fault notification API to send notifications,
possibly via VFIO, to the guest
DMA faults can be detected by IOMMU at device level. Adding a pointer
to struct device allows IOMMU subsystem to report relevant faults
back to the device driver for further handling.
For direct assigned device (or user space drivers), guest OS holds
responsibility to handle and respond per device
Traditionally, device specific faults are detected and handled within
their own device drivers. When IOMMU is enabled, faults such as DMA
related transactions are detected by IOMMU. There is no generic
reporting mechanism to report faults back to the in-kernel device
driver or the guest OS in case
This patch adds Intel VT-d specific function to implement
iommu passdown invalidate API for shared virtual address.
The use case is for supporting caching structure invalidation
of assigned SVM capable devices. Emulated IOMMU exposes queue
invalidation capability and passes down all descriptors fr
When nested translation is turned on and guest owns the
first level page tables, device page request can be forwared
to the guest for handling faults. As the page response returns
by the guest, IOMMU driver on the host need to process the
response which informs the device and completes the page req
With shared virtual memory vitualization, extended IOTLB invalidation
may be passed down from outside IOMMU subsystems. This patch adds
invalidation functions that can be used for each IOTLB types.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi L
Signed-off-by: Ashok Raj
---
drivers/iommu/dma
When SRIOV VF device IOTLB is invalidated, we need to provide
the PF source SID such that IOMMU hardware can gauge the depth
of invalidation queue which is shared among VFs. This is needed
when device invalidation throttle (DIT) capability is supported.
Signed-off-by: Jacob Pan
---
drivers/iommu
Hi All,
Shared virtual memory (SVM), or more precisely shared virtual address (SVA),
between device DMA and applications can reduce programming complexity
and enhance security. To enable SVM in the guest, i.e. shared guest application
address space and physical device DMA address, IOMMU driver mus
Add Intel VT-d ops to the generic iommu_bind_pasid_table API
functions.
The primary use case is for direct assignment of SVM capable
device. Originated from emulated IOMMU in the guest, the request goes
through many layers (e.g. VFIO). Upon calling host IOMMU driver, caller
passes guest PASID tabl
From: "Liu, Yi L"
When an SVM capable device is assigned to a guest, the first level page
tables are owned by the guest and the guest PASID table pointer is
linked to the device context entry of the physical IOMMU.
Host IOMMU driver has no knowledge of caching structure updates unless
the guest
Virtual IOMMU was proposed to support Shared Virtual Memory (SVM)
use in the guest:
https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg05311.html
As part of the proposed architecture, when an SVM capable PCI
device is assigned to a guest, nested mode is turned on. Guest owns the
first level
Allow both intel-iommu.c and dmar.c to access device_domain_info.
Prepare for additional per device arch data used in TLB flush function
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 18 --
include/linux/intel-iommu.h | 19 +++
2 files changed, 19 ins
IORT can be used (by QEMU) to describe a virtual topology containing an
architecture-agnostic paravirtualized device. The rationale behind this
blasphemy is explained in patch 4/5.
In order to build IORT for x86 systems, the driver has to be moved outside
of arm64/. Since there is nothing specific
To describe the virtual topology in relation to a virtio-iommu device,
ACPI-based systems use a "paravirtualized IOMMU" IORT node. Add support
for it.
This is a RFC because the IORT specification doesn't describe the
paravirtualized node at the moment, it is only provided as an example in
the virt
When the device offers the probe feature, send a probe request for each
device managed by the IOMMU. Extract RESV_MEM information. When we
encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
This will tell other subsystems that there is no need to map the MSI
doorbell in the virt
The event queue offers a way for the device to report access faults from
devices. It is implemented on virtqueue #1, whenever the host needs to
signal a fault it fills one of the buffers offered by the guest and
interrupts it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iommu.c
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio-mmio transport without emulating
page tables. This implementation handle ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code is to create requests and send them through virtio.
Imp
Implement the virtio-iommu driver following version 0.5 of the
specification [1]. Previous version of this code was sent back in April
[2], implementing the first public RFC. Since then there has been lots of
progress and discussion on the specification side, and I think the driver
is in a good sha
On Fri, 17 Nov 2017 17:44:57 +
Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Friday, November 17, 2017 7:48 AM
> |
> | Reported by: Harsh
> | Reviewed by: Ashok Raj
> | Tested by: Jacob Pan
>
> Thanks everyone! I've updated our internal bug on this issue
> and noted that we need t
| From: Raj, Ashok
| Sent: Friday, November 17, 2017 7:48 AM
|
| Reported by: Harsh
| Reviewed by: Ashok Raj
| Tested by: Jacob Pan
Thanks everyone! I've updated our internal bug on this issue
and noted that we need to track down the remaining problems
which may be in our own code.
Casey
__
Hi Alex
On Fri, Nov 17, 2017 at 09:18:14AM -0700, Alex Williamson wrote:
> On Thu, 16 Nov 2017 13:09:33 -0800
> "Raj, Ashok" wrote:
>
> > >
> > > What do we do about this? I certainly can't rip out large page support
> > > and put a stable tag on the patch. I'm not really spotting what's
> >
On Thu, 16 Nov 2017 13:09:33 -0800
"Raj, Ashok" wrote:
> Hi Alex
>
> On Thu, Nov 16, 2017 at 02:32:44PM -0700, Alex Williamson wrote:
> > On Wed, 15 Nov 2017 15:54:56 -0800
> > Jacob Pan wrote:
> >
> > > Hi Alex and all,
> > >
> > > Just wondering if you could merge Robin's patch for the ne
On 17/11/17 06:11, Bharat Kumar Gogada wrote:
[...]
> Thanks Jean, I see that currently vfio_group_fops_open does not allow
> multiple instances.
> If a device supports multiple PASID there might be different applications
> running parallel.
> So why is multiple instances restricted ?
You can'
34 matches
Mail list logo