Re: [PULL 00/27] KVM/ARM GICv4 Support for v4.15

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

[RFC PATCH v2 4/5] ACPI/IORT: Support paravirtualized IOMMU

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

[RFC PATCH v2 0/5] Add virtio-iommu driver

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

[RFC PATCH v2 1/5] iommu: Add virtio-iommu driver

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.

[RFC PATCH v2 5/5] ACPI/IORT: Move IORT to the ACPI folder

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

[RFC PATCH v2 2/5] iommu/virtio-iommu: Add probe request

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

[RFC PATCH v2 3/5] iommu/virtio-iommu: Add event queue

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

[PATCH] KVM: arm/arm64: VGIC: extend !vgic_is_initialized guard

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

[RFC PATCH 4/4] arm64/sve: KVM: Basic SVE support

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

[RFC PATCH 2/4] arm64/sve: KVM: Avoid dereference of dead task during guest entry

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

[RFC PATCH 0/4] Initial KVM SVE support hacks

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

[RFC PATCH 1/4] arm64: fpsimd: Abstract out binding of task's fpsimd context to the cpu.

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

[RFC PATCH 3/4] arm64/sve: KVM: Ensure user SVE use traps after vcpu execution

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

Re: [RFC PATCH 0/4] Initial KVM SVE support hacks

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