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
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
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
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
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
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
Commit f39d16cbabf9 ("KVM: arm/arm64: Guard kvm_vgic_map_is_active against
!vgic_initialized") introduced a check whether the VGIC has been
initialized before accessing the spinlock and the VGIC data structure.
However the vgic_get_irq() call in the variable declaration sneaked
through the net, so
On Fri, Nov 17, 2017 at 04:38:51PM +, Dave Martin wrote:
> Throwing out an RFC here now that I've got something _sort of_ working.
>
> This is based on the base SVE patches as now present in
> torvalds/master [1], but not on Christoffer's SVE optimisations (for
(That should be: Christoffer's
There is currently some duplicate logic to associate current's
FPSIMD context with the cpu when loading FPSIMD state into the cpu
regs.
Subsequent patches will update that logic, so in order to ensure it
only needs to be done in one place, this patch factors the relevant
code out into a new functi
This patch is a flattened bunch of hacks for adding SVE support to
KVM. It's intended as a starting point for comments: it is not
intended to be complete or final!
** This patch has suspected bugs and has undergone minimal testing: do
not merge **
Notes:
struct kvm_vpcu_arch does not currently
When deciding whether to invalidate FPSIMD state cached in the cpu,
the backend function sve_flush_cpu_state() attempts to dereference
__this_cpu_read(fpsimd_last_state). However, this is not safe:
there is no guarantee that the pointer is still valid, because the
task could have exited in the mea
Currently, SVE use can remain untrapped if a KVM vcpu thread is
preempted inside the kernel and we then switch back to some user
thread.
This patch ensures that SVE traps for userspace are enabled before
switching away from the vcpu thread.
In an attempt to preserve some clarity about why and whe
Throwing out an RFC here now that I've got something _sort of_ working.
This is based on the base SVE patches as now present in
torvalds/master [1], but not on Christoffer's SVE optimisations (for
now).
In a slightly older version of this code I have seen host user tasks
reaching task_fpsimd_save
On 13/11/2017 10:17, Christoffer Dall wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
> tags/kvm-arm-gicv4-for-v4.15
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mai
14 matches
Mail list logo