On Thu, May 30, 2019 at 06:09:24PM +0100, Jean-Philippe Brucker wrote:
> Some systems implement virtio-iommu as a PCI endpoint. The operating
> system needs to discover the relationship between IOMMU and masters long
> before the PCI endpoint gets probed. Add a PCI child node to describe the
>
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
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio transport without emulating page
tables. This implementation handles ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code transforms calls coming from the IOMMU API into
The event queue offers a way for the device to report access faults from
endpoints. 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.
Acked-by: Joerg Roedel
Reviewed-by: Eric Auger
Signed-off-by:
The nature of a virtio-mmio node is discovered by the virtio driver at
probe time. However the DMA relation between devices must be described
statically. When a virtio-mmio node is a virtio-iommu device, it needs an
"#iommu-cells" property as specified by bindings/iommu/iommu.txt.
Otherwise, the
For PCI devices that have an OF node, set the fwnode as well. This way
drivers that rely on fwnode don't need the special case described by
commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately").
Acked-by: Bjorn Helgaas
Signed-off-by: Jean-Philippe Brucker
---
In PCI root complex nodes, the iommu-map property describes the IOMMU that
translates each endpoint. On some platforms, the IOMMU itself is presented
as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). This isn't supported
by the current OF driver, which expects all endpoints to have an IOMMU.
Some systems implement virtio-iommu as a PCI endpoint. The operating
system needs to discover the relationship between IOMMU and masters long
before the PCI endpoint gets probed. Add a PCI child node to describe the
virtio-iommu device.
The virtio-pci-iommu is conceptually split between a PCI
Implement the virtio-iommu driver, following specification v0.12 [1].
Since last version [2] we've worked on improving the specification,
which resulted in the following changes to the interface:
* Remove the EXEC flag.
* Add feature bit for the MMIO flag.
* Change domain_bits to domain_range.
This patch adds --enable-sve/--disable-sve command line options to
allow the user to control whether the Scalable Vector Extension is
made available to the guest.
This requires use of the new KVM_ARM_VCPU_FINALIZE ioctl before the
vcpu is runnable, so a new hook kvm_cpu__configure_features() is
In the interest of readability, factor out the vcpu feature setup
for ptrauth into a separate function.
Also, because aarch32 doesn't have this feature or the related
command line options anyway, move the actual code into aarch64/.
Since ARM_VCPU_PTRAUTH_FEATURE is only there to make the ptrauth
In order to support use cases such as migration, it may be
important in some situations to restrict the set of SVE vector
lengths available to the guest. It can also be useful to observe
the behaviour of guest OSes with different vector lengths.
To enable testing and experimentation for such
To help the user understand what is going on, amend ptrauth
configuration diagnostic messages to refer to command line options
by the exact name used on the command line.
Also, provide a clean diagnostic when ptrauth is requested, but not
availble. The generic "Unable to initialise vcpu" message
From: Amit Daniel Kachhap
This patch adds a runtime capabality for KVM tool to enable Arm64 8.3
Pointer Authentication in guest kernel. Two vcpu features
KVM_ARM_VCPU_PTRAUTH_[ADDRESS/GENERIC] are supplied together to enable
Pointer Authentication in KVM guest after checking the capability.
The SVE KVM support for arm64 includes the additional backend
header from .
So update this header if it is available.
To avoid creating a sudden dependency on a specific minimum kernel
version, ignore the header if the source kernel tree doesn't have
it.
Signed-off-by: Dave Martin
---
Pull in upstream UAPI headers, for subsequent arm64 SVE / ptrauth
support (among other things).
Signed-off-by: Dave Martin
---
arm/aarch64/include/asm/kvm.h | 43
arm/aarch64/include/asm/sve_context.h | 53 +++
If in intermediate step fails, update_headers.sh blindly continues
and may return success status.
To avoid errors going unnoticed when driving this script, exit and
report failure status as soon as something goes wrong. For good
measure, also fail on expansion of undefined shell variables to aid
update_headers.sh can break if the current working directory has a
funny name or if something odd is passed for LINUX_ROOT.
In the interest of cleanliness, quote where appropriate.
Signed-off-by: Dave Martin
---
util/update_headers.sh | 10 +-
1 file changed, 5 insertions(+), 5
This series, based on kvmtool master [1], implements basic support for
pointer authentication and SVE for guests.
A git tree is also available [2].
For pointer auth, I include Amit's v10 patch [3], with some additional
refactoring to sit nicely alongside SVE, and some cosmetic / diagnostic
19 matches
Mail list logo
