Re: [CFT PATCH 0/2] KVM: support XSAVES usage in the host
I’ll try to check it tomorrow (I don’t have access to the failing machine at the moment). Thanks for the quick response. Nadav > On Nov 21, 2014, at 20:31, Paolo Bonzini wrote: > > The first patch ensures that XSAVES is not exposed in the guest until > we emulate MSR_IA32_XSS. The second exports XSAVE data in the correct > format. > > I tested these on a non-XSAVES system so they should not be completely > broken, but I need some help. I am not even sure which XSAVE states > are _not_ enabled, and thus compacted, in Linux. > > Note that these patches do not add support for XSAVES in the guest yet, > since MSR_IA32_XSS is not emulated. > > If they fix the bug Nadav reported, I'll add Reported-by and commit. > > Thanks, > > Paolo > > Paolo Bonzini (2): > kvm: x86: mask out XSAVES > KVM: x86: support XSAVES usage in the host > > arch/x86/kvm/cpuid.c | 11 ++- > arch/x86/kvm/x86.c | 48 +++- > 2 files changed, 53 insertions(+), 6 deletions(-) > > -- > 1.8.3.1 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CFT PATCH 0/2] KVM: support XSAVES usage in the host
Hi Nadav, On 11/23/14, 4:16 PM, Nadav Amit wrote: I’ll try to check it tomorrow (I don’t have access to the failing machine at the moment). If the machine you mentioned support xsaves and what's machine you are using? Regards, Wanpeng Li Thanks for the quick response. Nadav On Nov 21, 2014, at 20:31, Paolo Bonzini wrote: The first patch ensures that XSAVES is not exposed in the guest until we emulate MSR_IA32_XSS. The second exports XSAVE data in the correct format. I tested these on a non-XSAVES system so they should not be completely broken, but I need some help. I am not even sure which XSAVE states are _not_ enabled, and thus compacted, in Linux. Note that these patches do not add support for XSAVES in the guest yet, since MSR_IA32_XSS is not emulated. If they fix the bug Nadav reported, I'll add Reported-by and commit. Thanks, Paolo Paolo Bonzini (2): kvm: x86: mask out XSAVES KVM: x86: support XSAVES usage in the host arch/x86/kvm/cpuid.c | 11 ++- arch/x86/kvm/x86.c | 48 +++- 2 files changed, 53 insertions(+), 6 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CFT PATCH 0/2] KVM: support XSAVES usage in the host
> On Nov 23, 2014, at 10:24, Wanpeng Li wrote: > > Hi Nadav, > On 11/23/14, 4:16 PM, Nadav Amit wrote: >> I’ll try to check it tomorrow (I don’t have access to the failing machine at >> the moment). > > If the machine you mentioned support xsaves and what's machine you are using? It supports xsaves. I am using an experimental setup. Nadav-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CFT PATCH 0/2] KVM: support XSAVES usage in the host
On 11/23/14, 4:31 PM, Nadav Amit wrote: On Nov 23, 2014, at 10:24, Wanpeng Li wrote: Hi Nadav, On 11/23/14, 4:16 PM, Nadav Amit wrote: I’ll try to check it tomorrow (I don’t have access to the failing machine at the moment). If the machine you mentioned support xsaves and what's machine you are using? It supports xsaves. I am using an experimental setup. Interesting, I even can't get a machine which supports xsaves. Regards, Wanpeng Li Nadav -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL 02/15] pc: kvm: check if KVM has free memory slots to avoid abort()
From: Igor Mammedov
When more memory devices are used than available
KVM memory slots, QEMU crashes with:
kvm_alloc_slot: no free slot available
Aborted (core dumped)
Fix this by checking that KVM has a free slot before
attempting to map memory in guest address space.
Signed-off-by: Igor Mammedov
Acked-by: Paolo Bonzini
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/sysemu/kvm.h | 1 +
hw/i386/pc.c | 5 +
kvm-all.c| 18 +-
kvm-stub.c | 5 +
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b0cd657..22e42ef 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -163,6 +163,7 @@ extern KVMState *kvm_state;
/* external API */
+bool kvm_has_free_slot(MachineState *ms);
int kvm_has_sync_mmu(void);
int kvm_has_vcpu_events(void);
int kvm_has_robust_singlestep(void);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 1205db8..ce7b752 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1598,6 +1598,11 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
goto out;
}
+if (kvm_enabled() && !kvm_has_free_slot(machine)) {
+error_setg(&local_err, "hypervisor has no free memory slots left");
+goto out;
+}
+
memory_region_add_subregion(&pcms->hotplug_memory,
addr - pcms->hotplug_memory_base, mr);
vmstate_register_ram(mr, dev);
diff --git a/kvm-all.c b/kvm-all.c
index 596e7ce..937bc9d 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -132,7 +132,7 @@ static const KVMCapabilityInfo kvm_required_capabilites[] =
{
KVM_CAP_LAST_INFO
};
-static KVMSlot *kvm_alloc_slot(KVMState *s)
+static KVMSlot *kvm_get_free_slot(KVMState *s)
{
int i;
@@ -142,6 +142,22 @@ static KVMSlot *kvm_alloc_slot(KVMState *s)
}
}
+return NULL;
+}
+
+bool kvm_has_free_slot(MachineState *ms)
+{
+return kvm_get_free_slot(KVM_STATE(ms->accelerator));
+}
+
+static KVMSlot *kvm_alloc_slot(KVMState *s)
+{
+KVMSlot *slot = kvm_get_free_slot(s);
+
+if (slot) {
+return slot;
+}
+
fprintf(stderr, "%s: no free slot available\n", __func__);
abort();
}
diff --git a/kvm-stub.c b/kvm-stub.c
index 43fc0dd..7ba90c5 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -147,4 +147,9 @@ int kvm_irqchip_remove_irqfd_notifier(KVMState *s,
EventNotifier *n, int virq)
{
return -ENOSYS;
}
+
+bool kvm_has_free_slot(MachineState *ms)
+{
+return false;
+}
#endif
--
MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL 05/15] memory: expose alignment used for allocating RAM as MemoryRegion API
From: Igor Mammedov
introduce memory_region_get_alignment() that returns
underlying memory block alignment or 0 if it's not
relevant/implemented for backend.
Signed-off-by: Igor Mammedov
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/exec/exec-all.h | 2 +-
include/exec/memory.h | 2 ++
include/qemu/osdep.h| 3 ++-
exec.c | 9 ++---
memory.c| 5 +
target-s390x/kvm.c | 2 +-
util/oslib-posix.c | 5 -
util/oslib-win32.c | 2 +-
8 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 421a142..0844885 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -333,7 +333,7 @@ extern uintptr_t tci_tb_ptr;
#if !defined(CONFIG_USER_ONLY)
-void phys_mem_set_alloc(void *(*alloc)(size_t));
+void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align));
struct MemoryRegion *iotlb_to_region(AddressSpace *as, hwaddr index);
bool io_mem_read(struct MemoryRegion *mr, hwaddr addr,
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 74a58b4..f64ab5e 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -146,6 +146,7 @@ struct MemoryRegion {
hwaddr addr;
void (*destructor)(MemoryRegion *mr);
ram_addr_t ram_addr;
+uint64_t align;
bool subpage;
bool terminates;
bool romd_mode;
@@ -838,6 +839,7 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr,
*/
ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr);
+uint64_t memory_region_get_alignment(const MemoryRegion *mr);
/**
* memory_region_del_subregion: Remove a subregion.
*
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index c032434..b3300cc 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#ifdef __OpenBSD__
#include
@@ -103,7 +104,7 @@ typedef signed int int_fast16_t;
int qemu_daemon(int nochdir, int noclose);
void *qemu_try_memalign(size_t alignment, size_t size);
void *qemu_memalign(size_t alignment, size_t size);
-void *qemu_anon_ram_alloc(size_t size);
+void *qemu_anon_ram_alloc(size_t size, uint64_t *align);
void qemu_vfree(void *ptr);
void qemu_anon_ram_free(void *ptr, size_t size);
diff --git a/exec.c b/exec.c
index f0e2bd3..71ac104 100644
--- a/exec.c
+++ b/exec.c
@@ -909,14 +909,15 @@ static int subpage_register (subpage_t *mmio, uint32_t
start, uint32_t end,
uint16_t section);
static subpage_t *subpage_init(AddressSpace *as, hwaddr base);
-static void *(*phys_mem_alloc)(size_t size) = qemu_anon_ram_alloc;
+static void *(*phys_mem_alloc)(size_t size, uint64_t *align) =
+ qemu_anon_ram_alloc;
/*
* Set a custom physical guest memory alloator.
* Accelerators with unusual needs may need this. Hopefully, we can
* get rid of it eventually.
*/
-void phys_mem_set_alloc(void *(*alloc)(size_t))
+void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align))
{
phys_mem_alloc = alloc;
}
@@ -1098,6 +1099,7 @@ static void *file_ram_alloc(RAMBlock *block,
error_propagate(errp, local_err);
goto error;
}
+block->mr->align = hpagesize;
if (memory < hpagesize) {
error_setg(errp, "memory size 0x" RAM_ADDR_FMT " must be equal to "
@@ -1309,7 +1311,8 @@ static ram_addr_t ram_block_add(RAMBlock *new_block,
Error **errp)
if (xen_enabled()) {
xen_ram_alloc(new_block->offset, new_block->length, new_block->mr);
} else {
-new_block->host = phys_mem_alloc(new_block->length);
+new_block->host = phys_mem_alloc(new_block->length,
+ &new_block->mr->align);
if (!new_block->host) {
error_setg_errno(errp, errno,
"cannot set up guest memory '%s'",
diff --git a/memory.c b/memory.c
index 0f4fdc7..15cf9eb 100644
--- a/memory.c
+++ b/memory.c
@@ -1749,6 +1749,11 @@ ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr)
return mr->ram_addr;
}
+uint64_t memory_region_get_alignment(const MemoryRegion *mr)
+{
+return mr->align;
+}
+
static int cmp_flatrange_addr(const void *addr_, const void *fr_)
{
const AddrRange *addr = addr_;
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index d247471..50709ba 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -404,7 +404,7 @@ int kvm_arch_get_registers(CPUState *cs)
* to grow. We also have to use MAP parameters that avoid
* read-only mapping of guest pages.
*/
-static void *legacy_s390_alloc(size_t size)
+static void *legacy_s390_alloc(size_t size, , uint64_t *align)
{
void *mem;
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 8c9d80e..16fcec2 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -124,7 +124,7 @@ void *qemu_memalign(size_t ali
[PATCH v4 0/3] irqfd support for arm/arm64
This patch series enables irqfd on arm and arm64. Irqfd framework enables to inject a virtual IRQ into a guest upon an eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with a kvm_irqfd struct that associates a VM, an eventfd, a virtual IRQ number (aka. the gsi). When an actor signals the eventfd (typically a VFIO platform driver), the kvm irqfd subsystem injects the gsi into the VM. Resamplefd also is supported for level sensitive interrupts, ie. the user can provide another eventfd that is triggered when the completion of the virtual IRQ (gsi) is detected by the GIC. The gsi must correspond to a shared peripheral interrupt (SPI), ie the GIC interrupt ID is gsi + 32. The rationale behind not supporting PPI irqfd injection is that any device using a PPI would be a private-to-the-CPU device (timer for instance), so its state would have to be context-switched along with the VCPU and would require in-kernel wiring anyhow. It is not a relevant use case for irqfds. this patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD. No IRQ routing table is used, enabling to remove CONFIG_HAVE_KVM_IRQCHIP can be found at git://git.linaro.org/people/eric.auger/linux.git on branch irqfd_integ_v8 This work was tested with Calxeda Midway xgmac main interrupt with qemu-system-arm and QEMU VFIO platform device. Also irqfd was proven functional on several vhost-net prototypes. v3 -> v4: - rebase on 3.18rc5 - vgic dynamic instantiation brought new challenges: handling of irqfd injection when vgic is not ready - unset of CONFIG_HAVE_KVM_IRQCHIP in a separate patch - add arm64 enable - vgic.c style modifications according to Christoffer comments v2 -> v3: - removal of irq.h from eventfd.c put in a separate patch to increase visibility - properly expose KVM_CAP_IRQFD capability in arm.c - remove CONFIG_HAVE_KVM_IRQCHIP meaningfull only if irq_comm.c is used v1 -> v2: - rebase on 3.17rc1 - move of the dist unlock in process_maintenance - remove of dist lock in __kvm_vgic_sync_hwstate - rewording of the commit message (add resamplefd reference) - remove irq.h Eric Auger (2): KVM: arm/arm64: unset CONFIG_HAVE_KVM_IRQCHIP KVM: arm: add irqfd support Joel Schopp (1): KVM: arm64: add irqfd support Documentation/virtual/kvm/api.txt | 5 ++- arch/arm/include/uapi/asm/kvm.h | 3 ++ arch/arm/kvm/Kconfig | 4 +-- arch/arm/kvm/Makefile | 2 +- arch/arm/kvm/arm.c| 3 ++ arch/arm64/include/uapi/asm/kvm.h | 3 ++ arch/arm64/kvm/Kconfig| 3 +- arch/arm64/kvm/Makefile | 2 +- virt/kvm/arm/vgic.c | 72 --- 9 files changed, 87 insertions(+), 10 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] KVM: arm64: add irqfd support
From: Joel Schopp
This patch enables irqfd for arm64.
Signed-off-by: Joel Schopp
Signed-off-by: Eric Auger
---
[Eric Auger]
- originates from Joel's [RFC PATCH] arm64: KVM: add irqfd support
http://www.spinics.net/lists/kvm-arm/msg10798.html
- isolates modifications really related to irqfd
---
Documentation/virtual/kvm/api.txt | 4 ++--
arch/arm64/include/uapi/asm/kvm.h | 3 +++
arch/arm64/kvm/Kconfig| 2 ++
arch/arm64/kvm/Makefile | 2 +-
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 4deccc0..c76ce04 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2206,7 +2206,7 @@ into the hash PTE second double word).
4.75 KVM_IRQFD
Capability: KVM_CAP_IRQFD
-Architectures: x86 s390 arm
+Architectures: x86 s390 arm arm64
Type: vm ioctl
Parameters: struct kvm_irqfd (in)
Returns: 0 on success, -1 on error
@@ -2232,7 +2232,7 @@ Note that closing the resamplefd is not sufficient to
disable the
irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
-On arm, the gsi must be a shared peripheral interrupt (SPI).
+On arm/arm64, the gsi must be a shared peripheral interrupt (SPI).
This means the corresponding programmed GIC interrupt ID is gsi+32.
4.76 KVM_PPC_ALLOCATE_HTAB
diff --git a/arch/arm64/include/uapi/asm/kvm.h
b/arch/arm64/include/uapi/asm/kvm.h
index 8e38878..1ed4417 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -182,6 +182,9 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX127
+/* One single KVM irqchip, ie. the VGIC */
+#define KVM_NR_IRQCHIPS 1
+
/* PSCI interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 279e1a0..09c25c2 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -26,6 +26,7 @@ config KVM
select KVM_ARM_HOST
select KVM_ARM_VGIC
select KVM_ARM_TIMER
+ select HAVE_KVM_EVENTFD
---help---
Support hosting virtualized guest machines.
@@ -50,6 +51,7 @@ config KVM_ARM_MAX_VCPUS
config KVM_ARM_VGIC
bool
depends on KVM_ARM_HOST && OF
+ select HAVE_KVM_IRQFD
---help---
Adds support for a hardware assisted, in-kernel GIC emulation.
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 32a0961..2e6b827 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -11,7 +11,7 @@ ARM=../../../arch/arm/kvm
obj-$(CONFIG_KVM_ARM_HOST) += kvm.o
-kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o
+kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o
$(KVM)/eventfd.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/arm.o $(ARM)/mmu.o $(ARM)/mmio.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/psci.o $(ARM)/perf.o
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] KVM: arm: add irqfd support
This patch enables irqfd on arm.
Both irqfd and resamplefd are supported. Injection is implemented
in vgic.c without routing.
This patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD.
KVM_CAP_IRQFD is now advertised. KVM_CAP_IRQFD_RESAMPLE capability
automatically is advertised as soon as CONFIG_HAVE_KVM_IRQFD is set.
Signed-off-by: Eric Auger
---
v3 -> v4:
- reword commit message
- explain why we unlock the distributor before calling kvm_notify_acked_irq
- rename is_assigned_irq into has_notifier
- change EOI and injection kvm_debug format string
- remove error local variable in kvm_set_irq
- Move HAVE_KVM_IRQCHIP unset in a separate patch
- The rationale behind not supporting PPI irqfd injection is that
any device using a PPI would be a private-to-the-CPU device (timer for
instance), so its state would have to be context-switched along with the
VCPU and would require in-kernel wiring anyhow. It is not a relevant use
case for irqfds.
- handle case were the irqfd injection is attempted before the vgic is ready.
in such a case the notifier, if any, is called immediatly
- use nr_irqs to test spi is within correct range
v2 -> v3:
- removal of irq.h from eventfd.c put in a separate patch to increase
visibility
- properly expose KVM_CAP_IRQFD capability in arm.c
- remove CONFIG_HAVE_KVM_IRQCHIP meaningfull only if irq_comm.c is used
v1 -> v2:
- rebase on 3.17rc1
- move of the dist unlock in process_maintenance
- remove of dist lock in __kvm_vgic_sync_hwstate
- rewording of the commit message (add resamplefd reference)
- remove irq.h
---
Documentation/virtual/kvm/api.txt | 5 ++-
arch/arm/include/uapi/asm/kvm.h | 3 ++
arch/arm/kvm/Kconfig | 2 ++
arch/arm/kvm/Makefile | 2 +-
arch/arm/kvm/arm.c| 3 ++
virt/kvm/arm/vgic.c | 72 ---
6 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 7610eaa..4deccc0 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2206,7 +2206,7 @@ into the hash PTE second double word).
4.75 KVM_IRQFD
Capability: KVM_CAP_IRQFD
-Architectures: x86 s390
+Architectures: x86 s390 arm
Type: vm ioctl
Parameters: struct kvm_irqfd (in)
Returns: 0 on success, -1 on error
@@ -2232,6 +2232,9 @@ Note that closing the resamplefd is not sufficient to
disable the
irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
+On arm, the gsi must be a shared peripheral interrupt (SPI).
+This means the corresponding programmed GIC interrupt ID is gsi+32.
+
4.76 KVM_PPC_ALLOCATE_HTAB
Capability: KVM_CAP_PPC_ALLOC_HTAB
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index 09ee408..77547bb 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -196,6 +196,9 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX127
+/* One single KVM irqchip, ie. the VGIC */
+#define KVM_NR_IRQCHIPS 1
+
/* PSCI interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 9f581b1..e519a40 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -24,6 +24,7 @@ config KVM
select KVM_MMIO
select KVM_ARM_HOST
depends on ARM_VIRT_EXT && ARM_LPAE
+ select HAVE_KVM_EVENTFD
---help---
Support hosting virtualized guest machines. You will also
need to select one or more of the processor modules below.
@@ -55,6 +56,7 @@ config KVM_ARM_MAX_VCPUS
config KVM_ARM_VGIC
bool "KVM support for Virtual GIC"
depends on KVM_ARM_HOST && OF
+ select HAVE_KVM_IRQFD
default y
---help---
Adds support for a hardware assisted, in-kernel GIC emulation.
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index f7057ed..859db09 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -15,7 +15,7 @@ AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt)
AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt)
KVM := ../../../virt/kvm
-kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o
+kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o
obj-y += kvm-arm.o init.o interrupts.o
obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9e193c8..fb75af2 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -172,6 +172,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_IRQCHIP:
r = vgic_present;
break;
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD:
+#endif
case KVM_CAP_DEV
[PATCH v4 1/3] KVM: arm/arm64: unset CONFIG_HAVE_KVM_IRQCHIP
CONFIG_HAVE_KVM_IRQCHIP is needed to support IRQ routing (along with irq_comm.c and irqchip.c usage). This is not the case for arm/arm64 currently. This patch unsets the flag for both arm and arm64. Signed-off-by: Eric Auger --- arch/arm/kvm/Kconfig | 2 -- arch/arm64/kvm/Kconfig | 1 - 2 files changed, 3 deletions(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index 466bd29..9f581b1 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -55,7 +55,6 @@ config KVM_ARM_MAX_VCPUS config KVM_ARM_VGIC bool "KVM support for Virtual GIC" depends on KVM_ARM_HOST && OF - select HAVE_KVM_IRQCHIP default y ---help--- Adds support for a hardware assisted, in-kernel GIC emulation. @@ -63,7 +62,6 @@ config KVM_ARM_VGIC config KVM_ARM_TIMER bool "KVM support for Architected Timers" depends on KVM_ARM_VGIC && ARM_ARCH_TIMER - select HAVE_KVM_IRQCHIP default y ---help--- Adds support for the Architected Timers in virtual machines diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 8ba85e9..279e1a0 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -50,7 +50,6 @@ config KVM_ARM_MAX_VCPUS config KVM_ARM_VGIC bool depends on KVM_ARM_HOST && OF - select HAVE_KVM_IRQCHIP ---help--- Adds support for a hardware assisted, in-kernel GIC emulation. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/4] KVM: arm: vgic: handle irqfd forwarded IRQ injection before vgic readiness
This patch handles the case where irqfd attempts to inject
a forwarded IRQ before the vgic is ready to accept it. We
cannot simply return pretending nothing happened since the IRQ
will never be deactivated by the guest. Indeed, the corresponding
virtual IRQ cannot be injected into the guest and the host
must deactivate it.
Signed-off-by: Eric Auger
---
virt/kvm/arm/vgic.c | 20
1 file changed, 20 insertions(+)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 21419ac..27394b0 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -2672,6 +2672,13 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id,
u32 irq, int level, bool line_status)
{
unsigned int spi = irq + VGIC_NR_PRIVATE_IRQS;
+ struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, 0);
+ int phys_irq = vgic_get_phys_irq(vcpu, spi);
+ bool is_forwarded = (phys_irq >= 0);
+ unsigned long flags;
+ struct irq_desc *desc;
+ struct irq_data *d;
+ struct irq_chip *chip;
kvm_debug("irqfd sets vIRQ %d to %d\n", irq, level);
@@ -2679,6 +2686,19 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id,
if (spi > kvm->arch.vgic.nr_irqs)
return -EINVAL;
return kvm_vgic_inject_irq(kvm, 0, spi, level);
+ }
+
+ if (level && is_forwarded) {
+ /*
+* the virtual IRQ never is injected into the guest
+* it must be manually completed on host side.
+*/
+ desc = irq_to_desc(phys_irq);
+ raw_spin_lock_irqsave(&desc->lock, flags);
+ d = &desc->irq_data;
+ chip = desc->irq_data.chip;
+ chip->irq_eoi(d);
+ raw_spin_unlock_irqrestore(&desc->lock, flags);
} else if (level && kvm_irq_has_notifier(kvm, 0, irq)) {
/*
* any IRQ injected before vgic readiness is
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/4] KVM: arm: vgic: fix state machine for forwarded IRQ
Fix multiple injection of level sensitive forwarded IRQs.
With current code, the second injection fails since the state bitmaps
are not reset (process_maintenance is not called anymore).
New implementation follows those principles:
- A forwarded IRQ only can be sampled when it is pending
- when queueing the IRQ (programming the LR), the pending state is removed
as for edge sensitive IRQs
- an injection of a forwarded IRQ is considered always valid since
coming from the HW and level always is 1.
Signed-off-by: Eric Auger
---
v2 -> v3:
- integration in new vgic_can_sample_irq
- remove the pending state when programming the LR
v1 -> v2:
- fix vgic state bypass in vgic_queue_hwirq
Conflicts:
virt/kvm/arm/vgic.c
---
virt/kvm/arm/vgic.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index ccb3801..5484e3d 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -360,7 +360,10 @@ static void vgic_cpu_irq_clear(struct kvm_vcpu *vcpu, int
irq)
static bool vgic_can_sample_irq(struct kvm_vcpu *vcpu, int irq)
{
- return vgic_irq_is_edge(vcpu, irq) || !vgic_irq_is_queued(vcpu, irq);
+ bool is_forwarded = (vgic_get_phys_irq(vcpu, irq) >= 0);
+
+ return vgic_irq_is_edge(vcpu, irq) || !vgic_irq_is_queued(vcpu, irq) ||
+ (is_forwarded && vgic_dist_irq_is_pending(vcpu, irq));
}
static u32 mmio_data_read(struct kvm_exit_mmio *mmio, u32 mask)
@@ -1295,6 +1298,7 @@ static bool vgic_queue_irq(struct kvm_vcpu *vcpu, u8
sgi_source_id, int irq)
struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
struct vgic_lr vlr;
int lr;
+ bool is_forwarded = (vgic_get_phys_irq(vcpu, irq) >= 0);
/* Sanitize the input... */
BUG_ON(sgi_source_id & ~7);
@@ -1330,7 +1334,7 @@ static bool vgic_queue_irq(struct kvm_vcpu *vcpu, u8
sgi_source_id, int irq)
vlr.irq = irq;
vlr.source = sgi_source_id;
vlr.state = LR_STATE_PENDING;
- if (!vgic_irq_is_edge(vcpu, irq))
+ if (!vgic_irq_is_edge(vcpu, irq) && !is_forwarded)
vlr.state |= LR_EOI_INT;
vgic_set_lr(vcpu, lr, vlr);
@@ -1371,11 +1375,12 @@ static bool vgic_queue_sgi(struct kvm_vcpu *vcpu, int
irq)
static bool vgic_queue_hwirq(struct kvm_vcpu *vcpu, int irq)
{
+ bool is_forwarded = (vgic_get_phys_irq(vcpu, irq) >= 0);
if (!vgic_can_sample_irq(vcpu, irq))
return true; /* level interrupt, already queued */
if (vgic_queue_irq(vcpu, 0, irq)) {
- if (vgic_irq_is_edge(vcpu, irq)) {
+ if (vgic_irq_is_edge(vcpu, irq) || is_forwarded) {
vgic_dist_irq_clear_pending(vcpu, irq);
vgic_cpu_irq_clear(vcpu, irq);
} else {
@@ -1636,14 +1641,17 @@ static bool vgic_update_irq_pending(struct kvm *kvm,
int cpuid,
int edge_triggered, level_triggered;
int enabled;
bool ret = true;
+ bool is_forwarded;
spin_lock(&dist->lock);
vcpu = kvm_get_vcpu(kvm, cpuid);
+ is_forwarded = (vgic_get_phys_irq(vcpu, irq_num) >= 0);
+
edge_triggered = vgic_irq_is_edge(vcpu, irq_num);
level_triggered = !edge_triggered;
- if (!vgic_validate_injection(vcpu, irq_num, level)) {
+ if (!vgic_validate_injection(vcpu, irq_num, level) && !is_forwarded) {
ret = false;
goto out;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/4] KVM: arm: vgic: cleanup forwarded IRQs on destroy
When the VGIC is destroyed it must take care of
- restoring the forwarded IRQs in non forwarded state,
- deactivating the IRQ in case the guest left without doing it
- cleaning nodes of the phys_map rbtree
Signed-off-by: Eric Auger
---
virt/kvm/arm/vgic.c | 36
1 file changed, 36 insertions(+)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index f592219..21419ac 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
/*
* How the whole thing works (courtesy of Christoffer Dall):
@@ -102,6 +103,8 @@ static struct vgic_lr vgic_get_lr(const struct kvm_vcpu
*vcpu, int lr);
static void vgic_set_lr(struct kvm_vcpu *vcpu, int lr, struct vgic_lr lr_desc);
static void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
static void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
+static void vgic_clean_irq_phys_map(struct kvm_vcpu *vcpu,
+ struct rb_root *root);
static const struct vgic_ops *vgic_ops;
static const struct vgic_params *vgic;
@@ -1813,6 +1816,36 @@ static struct irq_phys_map *vgic_irq_map_search(struct
kvm_vcpu *vcpu,
return NULL;
}
+static void vgic_clean_irq_phys_map(struct kvm_vcpu *vcpu,
+ struct rb_root *root)
+{
+ unsigned long flags;
+
+ while (1) {
+ struct rb_node *node = rb_first(root);
+ struct irq_phys_map *map;
+ struct irq_desc *desc;
+ struct irq_data *d;
+ struct irq_chip *chip;
+
+ if (!node)
+ break;
+
+ map = container_of(node, struct irq_phys_map, node);
+ desc = irq_to_desc(map->phys_irq);
+
+ raw_spin_lock_irqsave(&desc->lock, flags);
+ d = &desc->irq_data;
+ chip = desc->irq_data.chip;
+ irqd_clr_irq_forwarded(d);
+ chip->irq_eoi(d);
+ raw_spin_unlock_irqrestore(&desc->lock, flags);
+
+ rb_erase(node, root);
+ kfree(map);
+ }
+}
+
int vgic_get_phys_irq(struct kvm_vcpu *vcpu, int virt_irq)
{
struct irq_phys_map *map;
@@ -1855,6 +1888,7 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
{
struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
+ vgic_clean_irq_phys_map(vcpu, &vgic_cpu->irq_phys_map);
kfree(vgic_cpu->pending_shared);
kfree(vgic_cpu->vgic_irq_lr_map);
vgic_cpu->pending_shared = NULL;
@@ -1920,6 +1954,8 @@ void kvm_vgic_destroy(struct kvm *kvm)
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_vgic_vcpu_destroy(vcpu);
+ vgic_clean_irq_phys_map(vcpu, &dist->irq_phys_map);
+
vgic_free_bitmap(&dist->irq_enabled);
vgic_free_bitmap(&dist->irq_level);
vgic_free_bitmap(&dist->irq_pending);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/4] KVM: arm: vgic: add forwarded irq rbtree lock
Add a lock related to the rb tree manipulation. The rb tree can be
searched in one thread (irqfd handler for instance) and map/unmap
may happen in another.
Signed-off-by: Eric Auger
---
v2 -> v3:
re-arrange lock sequence in vgic_map_phys_irq
---
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/vgic.c| 56 --
2 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index ea31ac6..9b3290b 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -220,6 +220,7 @@ struct vgic_dist {
unsigned long *irq_pending_on_cpu;
struct rb_root irq_phys_map;
+ spinlock_t rb_tree_lock;
#endif
};
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 5484e3d..f592219 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1750,9 +1750,22 @@ static struct rb_root *vgic_get_irq_phys_map(struct
kvm_vcpu *vcpu,
int vgic_map_phys_irq(struct kvm_vcpu *vcpu, int virt_irq, int phys_irq)
{
- struct rb_root *root = vgic_get_irq_phys_map(vcpu, virt_irq);
- struct rb_node **new = &root->rb_node, *parent = NULL;
+ struct rb_root *root;
+ struct rb_node **new, *parent = NULL;
struct irq_phys_map *new_map;
+ struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
+
+ root = vgic_get_irq_phys_map(vcpu, virt_irq);
+ new = &root->rb_node;
+
+ new_map = kzalloc(sizeof(*new_map), GFP_KERNEL);
+ if (!new_map)
+ return -ENOMEM;
+
+ new_map->virt_irq = virt_irq;
+ new_map->phys_irq = phys_irq;
+
+ spin_lock(&dist->rb_tree_lock);
/* Boilerplate rb_tree code */
while (*new) {
@@ -1764,19 +1777,16 @@ int vgic_map_phys_irq(struct kvm_vcpu *vcpu, int
virt_irq, int phys_irq)
new = &(*new)->rb_left;
else if (this->virt_irq > virt_irq)
new = &(*new)->rb_right;
- else
+ else {
+ kfree(new_map);
+ spin_unlock(&dist->rb_tree_lock);
return -EEXIST;
+ }
}
- new_map = kzalloc(sizeof(*new_map), GFP_KERNEL);
- if (!new_map)
- return -ENOMEM;
-
- new_map->virt_irq = virt_irq;
- new_map->phys_irq = phys_irq;
-
rb_link_node(&new_map->node, parent, new);
rb_insert_color(&new_map->node, root);
+ spin_unlock(&dist->rb_tree_lock);
return 0;
}
@@ -1805,24 +1815,39 @@ static struct irq_phys_map *vgic_irq_map_search(struct
kvm_vcpu *vcpu,
int vgic_get_phys_irq(struct kvm_vcpu *vcpu, int virt_irq)
{
- struct irq_phys_map *map = vgic_irq_map_search(vcpu, virt_irq);
+ struct irq_phys_map *map;
+ struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
+ int ret;
+
+ spin_lock(&dist->rb_tree_lock);
+ map = vgic_irq_map_search(vcpu, virt_irq);
if (map)
- return map->phys_irq;
+ ret = map->phys_irq;
+ else
+ ret = -ENOENT;
+
+ spin_unlock(&dist->rb_tree_lock);
+ return ret;
- return -ENOENT;
}
int vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, int virt_irq, int phys_irq)
{
- struct irq_phys_map *map = vgic_irq_map_search(vcpu, virt_irq);
+ struct irq_phys_map *map;
+ struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
+
+ spin_lock(&dist->rb_tree_lock);
+
+ map = vgic_irq_map_search(vcpu, virt_irq);
if (map && map->phys_irq == phys_irq) {
rb_erase(&map->node, vgic_get_irq_phys_map(vcpu, virt_irq));
kfree(map);
+ spin_unlock(&dist->rb_tree_lock);
return 0;
}
-
+ spin_unlock(&dist->rb_tree_lock);
return -ENOENT;
}
@@ -2078,6 +2103,7 @@ int kvm_vgic_create(struct kvm *kvm)
}
spin_lock_init(&kvm->arch.vgic.lock);
+ spin_lock_init(&kvm->arch.vgic.rb_tree_lock);
kvm->arch.vgic.in_kernel = true;
kvm->arch.vgic.vctrl_base = vgic->vctrl_base;
kvm->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/4] vgic additions for forwarded irq
This series applies on top of "ARM: Forwarding physical interrupts to a guest VM" (http://lwn.net/Articles/603514/) series. It brings some extra functionalities that were requested to be able to inject virtual level sensitive IRQs triggered from VFIO/irqfd. It adds: - a specific handling of forwarded IRQ into the VGIC state machine. - deactivation of physical IRQ and unforwarding on vgic destruction - handling of forwarded IRQ injection before the vgic readiness: this was needed because in a sample qemu/vfio use case, qemu registers forwarded IRQ and set up VFIO signaling before the first vcpu run and hence before vgic readiness. At that time some physical IRQ may hit before the VGIC readiness. This is typically observed with Calxeda xgmac on second QEMU run. - rbtree lock addition. Integrated pieces can be found at ssh://git.linaro.org/people/eric.auger/linux.git on branch irqfd_integ_v8 The first 2 patch files were previously part of [RFC v2 0/9] KVM-VFIO IRQ forward control (https://lkml.org/lkml/2014/9/1/347). Eric Auger (4): KVM: arm: vgic: fix state machine for forwarded IRQ KVM: arm: vgic: add forwarded irq rbtree lock KVM: arm: vgic: cleanup forwarded IRQs on destroy KVM: arm: vgic: handle irqfd forwarded IRQ injection before vgic readiness include/kvm/arm_vgic.h | 1 + virt/kvm/arm/vgic.c| 128 + 2 files changed, 110 insertions(+), 19 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/8] KVM: arm64: Enable the KVM-VFIO device
Used by KVM-enabled VFIO-based device passthrough support in QEMU. Signed-off-by: Joel Schopp Signed-off-by: Eric Auger --- Extracted from [RFC PATCH] arm64: KVM: add irqfd support http://www.spinics.net/lists/kvm-arm/msg10798.html --- arch/arm64/kvm/Kconfig | 1 + arch/arm64/kvm/Makefile | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 09c25c2..2edf926 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -26,6 +26,7 @@ config KVM select KVM_ARM_HOST select KVM_ARM_VGIC select KVM_ARM_TIMER + select KVM_VFIO select HAVE_KVM_EVENTFD ---help--- Support hosting virtualized guest machines. diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile index 2e6b827..81ed091 100644 --- a/arch/arm64/kvm/Makefile +++ b/arch/arm64/kvm/Makefile @@ -11,7 +11,7 @@ ARM=../../../arch/arm/kvm obj-$(CONFIG_KVM_ARM_HOST) += kvm.o -kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vfio.o kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/arm.o $(ARM)/mmu.o $(ARM)/mmio.o kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/psci.o $(ARM)/perf.o -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/8] KVM: kvm-vfio: User API for IRQ forwarding
This patch adds and document a new KVM_DEV_VFIO_DEVICE group
and 2 device attributes: KVM_DEV_VFIO_DEVICE_FORWARD_IRQ,
KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ. The purpose is to be able
to set a VFIO device IRQ as forwarded or not forwarded.
the command takes as argument a handle to a new struct named
kvm_arch_forwarded_irq.
Signed-off-by: Eric Auger
---
v2 -> v3:
- rework vfio kvm device documentation
- reword commit message and title
- add subindex in kvm_arch_forwarded_irq to be closer to VFIO API
- forwarding state can only be changed with VFIO IRQ signaling is off
v1 -> v2:
- struct kvm_arch_forwarded_irq moved from arch/arm/include/uapi/asm/kvm.h
to include/uapi/linux/kvm.h
also irq_index renamed into index and guest_irq renamed into gsi
- ASSIGN/DEASSIGN renamed into FORWARD/UNFORWARD
---
Documentation/virtual/kvm/devices/vfio.txt | 34 --
include/uapi/linux/kvm.h | 10 +
2 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vfio.txt
b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..f7aff29 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -4,15 +4,24 @@ VFIO virtual device
Device types supported:
KVM_DEV_TYPE_VFIO
-Only one VFIO instance may be created per VM. The created device
-tracks VFIO groups in use by the VM and features of those groups
-important to the correctness and acceleration of the VM. As groups
-are enabled and disabled for use by the VM, KVM should be updated
-about their presence. When registered with KVM, a reference to the
-VFIO-group is held by KVM.
+Only one VFIO instance may be created per VM.
+
+The created device tracks VFIO groups in use by the VM and features
+of those groups important to the correctness and acceleration of
+the VM. As groups are enabled and disabled for use by the VM, KVM
+should be updated about their presence. When registered with KVM,
+a reference to the VFIO-group is held by KVM.
+
+The device also tracks & enable VFIO device forwarded IRQs, if any.
+A physical forwarded IRQ is directly completed by the guest. This
+requires HW support in the interrupt controller which must be able
+to automatically complete the physical IRQ when it detects the guest
+has completed the corresponding virtual IRQ. The modality sometimes
+is named direct EOI.
Groups:
KVM_DEV_VFIO_GROUP
+ KVM_DEV_VFIO_DEVICE
KVM_DEV_VFIO_GROUP attributes:
KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
@@ -20,3 +29,16 @@ KVM_DEV_VFIO_GROUP attributes:
For each, kvm_device_attr.addr points to an int32_t file descriptor
for the VFIO group.
+
+KVM_DEV_VFIO_DEVICE attributes:
+ KVM_DEV_VFIO_DEVICE_FORWARD_IRQ: set a VFIO device IRQ as forwarded
+ KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ: set a VFIO device IRQ as not forwarded
+
+For each, kvm_device_attr.addr points to a kvm_arch_forwarded_irq struct.
+
+The forwarded state can only be changed when the VFIO signaling mechanism
+for this physical IRQ is not set. In other words, forwarding must be
+activated before VFIO_DEVICE_SET_IRQS has been called to trigger the IRQ
+or associate an eventfd to it. Unforwarding can only be called while the
+signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this condition is
+not satisfied, the command returns an -EBUSY.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 6076882..a269a42 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -946,6 +946,9 @@ struct kvm_device_attr {
#define KVM_DEV_VFIO_GROUP1
#define KVM_DEV_VFIO_GROUP_ADD 1
#define KVM_DEV_VFIO_GROUP_DEL 2
+#define KVM_DEV_VFIO_DEVICE 2
+#define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1
+#define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ2
enum kvm_device_type {
KVM_DEV_TYPE_FSL_MPIC_20= 1,
@@ -963,6 +966,13 @@ enum kvm_device_type {
KVM_DEV_TYPE_MAX,
};
+struct kvm_arch_forwarded_irq {
+ __u32 fd; /* file desciptor of the VFIO device */
+ __u32 index; /* VFIO device IRQ index */
+ __u32 subindex; /* VFIO device IRQ subindex */
+ __u32 gsi; /* gsi, ie. virtual IRQ number */
+};
+
/*
* ioctls for VM fds
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/8] KVM: arm: kvm-vfio: forwarding control
This patch sets __KVM_HAVE_ARCH_KVM_VFIO_FORWARD and implements
kvm_arch_vfio_set_forward for ARM.
As a result the KVM-VFIO device now allows to forward/unforward a
VFIO device IRQ on ARM.
kvm_arch_vfio_set_forward programs both genirq and the VGIC to control
where the physical IRQ deactivation is initiated.
- forwarded case: deactivation is initiated by the guest; when it
completes the virtual IRQ, the GIC automatically deactivates the
physical IRQ.
- not forwarded case: the physical IRQ deactivation is handled by the host
Signed-off-by: Eric Auger
---
v2 -> v3:
- renaming of kvm_arch_set_fwd_state into kvm_arch_vfio_set_forward
- takes a bool arg instead of kvm_fwd_irq_action enum
- removal of KVM_VFIO_IRQ_CLEANUP
- platform device check now happens here
- more precise errors returned
- irq_eoi handled externally to this patch (VGIC)
- correct enable_irq bug done twice
- reword the commit message
- correct check of platform_bus_type
- use raw_spin_lock_irqsave and check the validity of the handler
---
arch/arm/include/asm/kvm_host.h | 2 +
arch/arm/kvm/Makefile | 2 +-
arch/arm/kvm/kvm_vfio_arm.c | 101
3 files changed, 104 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/kvm/kvm_vfio_arm.c
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index bca5b79..447f90c 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -27,6 +27,8 @@
#include
#include
+#define __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
+
#if defined(CONFIG_KVM_ARM_MAX_VCPUS)
#define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
#else
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index ea1fa76..26a5a42 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -19,7 +19,7 @@ kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o
$(KVM)/eventfd.o $(KVM)/vf
obj-y += kvm-arm.o init.o interrupts.o
obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
-obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
+obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o kvm_vfio_arm.o
obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic.o
obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic-v2.o
obj-$(CONFIG_KVM_ARM_TIMER) += $(KVM)/arm/arch_timer.o
diff --git a/arch/arm/kvm/kvm_vfio_arm.c b/arch/arm/kvm/kvm_vfio_arm.c
new file mode 100644
index 000..af2c501
--- /dev/null
+++ b/arch/arm/kvm/kvm_vfio_arm.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ * Authors: Eric Auger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * kvm_arch_vfio_set_forward - Change the forward state of an IRQ
+ *
+ * @fwd_irq: handle to the forward irq struct
+ * @forward: target forwarding state
+ *
+ * If forward is true, programs genirq and VGIC so that physical IRQ
+ * deactivation ownership is transferred to the guest (using GIC HW feature).
+ * When forward is false, standard behavior is restored, ie. host
+ * deactivates the physical IRQ.
+ * returns:
+ * -EINVAL if the vfio device is not a platform device
+ * -ENOENT if the irq could not be identified
+ * -EBUSY if physical IRQ is in progress
+ * -ENOENT if the VGIC has a physical/virtual IRQ mapping that is not
+ * consistent with the request.
+ */
+int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
+ bool forward)
+{
+ int hwirq;
+ int ret = -EBUSY;
+ struct irq_desc *desc;
+ struct irq_data *d;
+ struct platform_device *platdev;
+ struct device *dev = kvm_vfio_external_base_device(fwd_irq->vdev);
+ unsigned long flags;
+ /*
+* We don't have to garantee the vcpu handle is non void since the
+* vfio device holds a reference to the kvm struct
+*/
+ struct kvm_vcpu *vcpu = kvm_get_vcpu(fwd_irq->kvm, 0);
+
+ if (dev->bus == &platform_bus_type) {
+ platdev = to_platform_device(dev);
+ hwirq = platform_get_irq(platdev, fwd_irq->index);
+ if (hwirq < 0)
+ return -EINVAL;
+ } else
+ return -ENOENT;
+ desc = irq_to_desc(hwirq);
+
+ /*
+* if VFIO handler is already set, forwarded state cannot be
+* changed anymore
+*/
+ raw_spin_lock_irqsave(&desc->lock, flags);
+ if (desc->action)
+ goto end;
+
+ d = &desc->irq_data;
+
+
[PATCH v3 6/8] KVM: kvm-vfio: wrapper to VFIO external API device helpers
Provide wrapper functions that allow KVM-VFIO device code to
interact with a vfio device:
- kvm_vfio_device_get_external_user gets a handle to a struct
vfio_device from the vfio device file descriptor and increments
its reference counter,
- kvm_vfio_device_put_external_user decrements the reference counter
to a vfio device,
- kvm_vfio_external_base_device returns a handle to the struct device
of the vfio device.
The KVM-VFIO device uses the VFIO external API device functions.
Signed-off-by: Eric Auger
---
v2 -> v3:
reword the commit message and title
v1 -> v2:
- kvm_vfio_external_get_base_device renamed into
kvm_vfio_external_base_device
- kvm_vfio_external_get_type removed
---
arch/arm/include/asm/kvm_host.h | 5 +
virt/kvm/vfio.c | 45 +
2 files changed, 50 insertions(+)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 53036e2..bca5b79 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -169,6 +169,11 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva,
pte_t pte);
unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
+struct vfio_device;
+struct vfio_device *kvm_vfio_device_get_external_user(struct file *filep);
+void kvm_vfio_device_put_external_user(struct vfio_device *vdev);
+struct device *kvm_vfio_external_base_device(struct vfio_device *vdev);
+
/* We do not have shadow page tables, hence the empty hooks */
static inline int kvm_age_hva(struct kvm *kvm, unsigned long start,
unsigned long end)
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 620e37f..6f0cc34 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -60,6 +60,51 @@ static void kvm_vfio_group_put_external_user(struct
vfio_group *vfio_group)
symbol_put(vfio_group_put_external_user);
}
+struct vfio_device *kvm_vfio_device_get_external_user(struct file *filep)
+{
+ struct vfio_device *vdev;
+ struct vfio_device *(*fn)(struct file *);
+
+ fn = symbol_get(vfio_device_get_external_user);
+ if (!fn)
+ return ERR_PTR(-EINVAL);
+
+ vdev = fn(filep);
+
+ symbol_put(vfio_device_get_external_user);
+
+ return vdev;
+}
+
+void kvm_vfio_device_put_external_user(struct vfio_device *vdev)
+{
+ void (*fn)(struct vfio_device *);
+
+ fn = symbol_get(vfio_device_put_external_user);
+ if (!fn)
+ return;
+
+ fn(vdev);
+
+ symbol_put(vfio_device_put_external_user);
+}
+
+struct device *kvm_vfio_external_base_device(struct vfio_device *vdev)
+{
+ struct device *(*fn)(struct vfio_device *);
+ struct device *dev;
+
+ fn = symbol_get(vfio_external_base_device);
+ if (!fn)
+ return NULL;
+
+ dev = fn(vdev);
+
+ symbol_put(vfio_external_base_device);
+
+ return dev;
+}
+
static bool kvm_vfio_group_is_coherent(struct vfio_group *vfio_group)
{
long (*fn)(struct vfio_group *, unsigned long);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/8] KVM: kvm-vfio: generic forwarding control
This patch introduces a new KVM_DEV_VFIO_DEVICE group.
This is a new control channel which enables KVM to cooperate with
viable VFIO devices.
Functions are introduced to check the validity of a VFIO device
file descriptor, increment/decrement the ref counter of the VFIO
device.
The patch introduces 2 attributes for this new device group:
KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ.
Their purpose is to turn a VFIO device IRQ into a forwarded IRQ and
unset respectively unset the feature.
The VFIO device stores a list of registered forwarded IRQs. The reference
counter of the device is incremented each time a new IRQ is forwarded.
Reference counter is decremented when the IRQ forwarding is unset.
The forwarding programmming is architecture specific, implemented in
kvm_arch_set_fwd_state function. Architecture specific implementation is
enabled when __KVM_HAVE_ARCH_KVM_VFIO_FORWARD is set. When not set those
functions are void.
Signed-off-by: Eric Auger
---
v2 -> v3:
- add API comments in kvm_host.h
- improve the commit message
- create a private kvm_vfio_fwd_irq struct
- fwd_irq_action replaced by a bool and removal of VFIO_IRQ_CLEANUP. This
latter action will be handled in vgic.
- add a vfio_device handle argument to kvm_arch_set_fwd_state. The goal is
to move platform specific stuff in architecture specific code.
- kvm_arch_set_fwd_state renamed into kvm_arch_vfio_set_forward
- increment the ref counter each time we do an IRQ forwarding and decrement
this latter each time one IRQ forward is unset. Simplifies the whole
ref counting.
- simplification of list handling: create, search, removal
v1 -> v2:
- __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
- original patch file separated into 2 parts: generic part moved in vfio.c
and ARM specific part(kvm_arch_set_fwd_state)
---
include/linux/kvm_host.h | 28 ++
virt/kvm/vfio.c | 249 ++-
2 files changed, 274 insertions(+), 3 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ea53b04..0b9659d 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1076,6 +1076,15 @@ struct kvm_device_ops {
unsigned long arg);
};
+/* internal self-contained structure describing a forwarded IRQ */
+struct kvm_fwd_irq {
+ struct kvm *kvm; /* VM to inject the GSI into */
+ struct vfio_device *vdev; /* vfio device the IRQ belongs to */
+ __u32 index; /* VFIO device IRQ index */
+ __u32 subindex; /* VFIO device IRQ subindex */
+ __u32 gsi; /* gsi, ie. virtual IRQ number */
+};
+
void kvm_device_get(struct kvm_device *dev);
void kvm_device_put(struct kvm_device *dev);
struct kvm_device *kvm_device_from_filp(struct file *filp);
@@ -1085,6 +1094,25 @@ void kvm_unregister_device_ops(u32 type);
extern struct kvm_device_ops kvm_mpic_ops;
extern struct kvm_device_ops kvm_xics_ops;
+#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
+/**
+ * kvm_arch_vfio_set_forward - changes the forwarded state of an IRQ
+ *
+ * @fwd_irq: handle to the forwarded irq struct
+ * @forward: true means forwarded, false means not forwarded
+ * returns 0 on success, < 0 on failure
+ */
+int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
+ bool forward);
+
+#else
+static inline int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
+ bool forward)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool val)
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index 6f0cc34..af178bb 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -25,8 +25,16 @@ struct kvm_vfio_group {
struct vfio_group *vfio_group;
};
+/* private linkable kvm_fwd_irq struct */
+struct kvm_vfio_fwd_irq_node {
+ struct list_head link;
+ struct kvm_fwd_irq fwd_irq;
+};
+
struct kvm_vfio {
struct list_head group_list;
+ /* list of registered VFIO forwarded IRQs */
+ struct list_head fwd_node_list;
struct mutex lock;
bool noncoherent;
};
@@ -247,12 +255,239 @@ static int kvm_vfio_set_group(struct kvm_device *dev,
long attr, u64 arg)
return -ENXIO;
}
+/**
+ * kvm_vfio_get_vfio_device - Returns a handle to a vfio-device
+ *
+ * Checks it is a valid vfio device and increments its reference counter
+ * @fd: file descriptor of the vfio platform device
+ */
+static struct vfio_device *kvm_vfio_get_vfio_device(int fd)
+{
+ struct fd f = fdget(fd);
+ struct vfio_device *vdev;
+
+ if (!f.file)
+ return NULL;
+ vdev = kvm_vfio_device_get_external_user(f.file);
+ fdput(f);
+ return vdev;
+}
+
+/**
+ * kvm_vfio_put_vfio_device: decrements the reference counter of the
+ * vfio platform * device
+ *
+ * @vdev: vfio_device handle to release
+ */
+stat
[PATCH v3 5/8] VFIO: External user API device helpers
The VFIO external user API is enriched with 3 new functions that
allows a kernel user external to VFIO to retrieve some information
from a VFIO device.
- vfio_device_get_external_user enables to get a vfio device from
its fd and increments its reference counter
- vfio_device_put_external_user decrements the reference counter
- vfio_external_base_device returns a handle to the struct device
Signed-off-by: Eric Auger
---
v2 -> v3:
- reword the commit message
v1 -> v2:
- vfio_external_get_base_device renamed into vfio_external_base_device
- vfio_external_get_type removed
---
drivers/vfio/vfio.c | 24
include/linux/vfio.h | 3 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 8e84471..282814e 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1401,6 +1401,30 @@ void vfio_group_put_external_user(struct vfio_group
*group)
}
EXPORT_SYMBOL_GPL(vfio_group_put_external_user);
+struct vfio_device *vfio_device_get_external_user(struct file *filep)
+{
+ struct vfio_device *vdev = filep->private_data;
+
+ if (filep->f_op != &vfio_device_fops)
+ return ERR_PTR(-EINVAL);
+
+ vfio_device_get(vdev);
+ return vdev;
+}
+EXPORT_SYMBOL_GPL(vfio_device_get_external_user);
+
+void vfio_device_put_external_user(struct vfio_device *vdev)
+{
+ vfio_device_put(vdev);
+}
+EXPORT_SYMBOL_GPL(vfio_device_put_external_user);
+
+struct device *vfio_external_base_device(struct vfio_device *vdev)
+{
+ return vdev->dev;
+}
+EXPORT_SYMBOL_GPL(vfio_external_base_device);
+
int vfio_external_user_iommu_id(struct vfio_group *group)
{
return iommu_group_id(group->iommu_group);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 2fb2e30..08e33ec 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -99,6 +99,9 @@ extern void vfio_group_put_external_user(struct vfio_group
*group);
extern int vfio_external_user_iommu_id(struct vfio_group *group);
extern long vfio_external_check_extension(struct vfio_group *group,
unsigned long arg);
+extern struct vfio_device *vfio_device_get_external_user(struct file *filep);
+extern void vfio_device_put_external_user(struct vfio_device *vdev);
+extern struct device *vfio_external_base_device(struct vfio_device *vdev);
struct pci_dev;
#ifdef CONFIG_EEH
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/8] VFIO: platform: forwarded state tested when selecting IRQ handler
In case the IRQ is forwarded, the VFIO platform IRQ handler does not
need to disable the IRQ anymore.
When setting the IRQ handler we now also test the forwarded state. In
case the IRQ is forwarded we select the edge handler (no automaske).
Signed-off-by: Eric Auger
---
v2 -> v3:
- forwarded state was tested in the handler. Now the forwarded state
is tested before setting the handler. This definitively limits
the dynamics of forwarded state changes but I don't think there is
a use case where we need to be able to change the state at any time.
---
drivers/vfio/platform/vfio_platform_irq.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/platform/vfio_platform_irq.c
b/drivers/vfio/platform/vfio_platform_irq.c
index 08d400e..61a2920 100644
--- a/drivers/vfio/platform/vfio_platform_irq.c
+++ b/drivers/vfio/platform/vfio_platform_irq.c
@@ -230,8 +230,13 @@ static int vfio_platform_set_irq_trigger(struct
vfio_platform_device *vdev,
{
struct vfio_platform_irq *irq = &vdev->irqs[index];
irq_handler_t handler;
+ struct irq_data *d;
+ bool is_forwarded;
- if (vdev->irqs[index].flags & VFIO_IRQ_INFO_MASKABLE)
+ d = irq_get_irq_data(irq->hwirq);
+ is_forwarded = irqd_irq_forwarded(d);
+
+ if ((vdev->irqs[index].flags & VFIO_IRQ_INFO_MASKABLE) && !is_forwarded)
handler = vfio_maskable_irq_handler;
else
handler = vfio_irq_handler;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/8] KVM: arm: Enable the KVM-VFIO device
From: Kim Phillips Used by KVM-enabled VFIO-based device passthrough support in QEMU. Signed-off-by: Kim Phillips --- arch/arm/kvm/Kconfig | 1 + arch/arm/kvm/Makefile | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index e519a40..aace254 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -24,6 +24,7 @@ config KVM select KVM_MMIO select KVM_ARM_HOST depends on ARM_VIRT_EXT && ARM_LPAE + select KVM_VFIO select HAVE_KVM_EVENTFD ---help--- Support hosting virtualized guest machines. You will also diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile index 859db09..ea1fa76 100644 --- a/arch/arm/kvm/Makefile +++ b/arch/arm/kvm/Makefile @@ -15,7 +15,7 @@ AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt) AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt) KVM := ../../../virt/kvm -kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o +kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vfio.o obj-y += kvm-arm.o init.o interrupts.o obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/8] KVM-VFIO IRQ forward control
This series proposes an integration of "ARM: Forwarding physical interrupts to a guest VM" (http://lwn.net/Articles/603514/) in KVM. It enables to transform a VFIO platform driver IRQ into a forwarded IRQ. When a physical IRQ is forwarded (to a guest), the host does not deactivates this latter. Completion ownership is transferred to the guest. When the guest deactivates the associated virtual IRQ, the interrupt controler automatically completes the physical IRQ. Obviously this requires some dedicated HW support in the interrupt controler. The direct benefit is that, for a level sensitive IRQ, it avoids a VM exit on forwarded IRQ completion. When the IRQ is forwarded, the VFIO platform driver does not need to mask the physical IRQ anymore before signaling the eventfd. Indeed genirq lowers the running priority, enabling other physical IRQ to hit except that one. Besides, the injection still is based on irqfd triggering. The only impact on irqfd process is resamplefd is not called anymore on virtual IRQ completion since this latter becomes "transparent". The current integration is based on an extension of the KVM-VFIO device, previously used by KVM to interact with VFIO groups. The patch series now enables KVM to directly interact with a VFIO platform device. The VFIO external API was extended for that purpose. Th KVM-VFIO device can get/put the vfio platform device, check its integrity and type, get the IRQ number associated to an IRQ index. The IRQ forward programming is architecture specific (virtual interrupt controller programming basically). However the whole infrastructure is kept generic. from a user point of view, the functionality is provided through a new KVM-VFIO group named KVM_DEV_VFIO_DEVICE and 2 associated attributes: - KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, - KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ. The capability can be checked with KVM_HAS_DEVICE_ATTR. Forwarding must be activated before VFIO signaling mechanism is set using VFIO_DEVICE_SET_IRQS and unset while the signaling is disabled. --- This patch series has the following dependencies: - "ARM: Forwarding physical interrupts to a guest VM" (http://lwn.net/Articles/603514/) - [PATCH v9 00/19] VFIO support for platform and AMBA devices on ARM (http://www.spinics.net/lists/kvm-arm/msg11745.html) - [PATCH v2 0/6] vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1 (http://www.spinics.net/lists/kvm-arm/msg11738.html) Integrated pieces can be found at ssh://git.linaro.org/people/eric.auger/linux.git on branch irqfd_integ_v8 This was was tested on Calxeda Midway, assigning the xgmac main IRQ. v2 -> v3: - kvm_fwd_irq_action enum replaced by a bool (KVM_VFIO_IRQ_CLEANUP does not exist anymore) - a new struct local to vfio.c was introduced to wrap kvm_fw_irq and make it linkable: kvm_vfio_fwd_irq_node - kvm_fwd_irq now is self-contained (includes struct vfio_device *) - a single list of kvm_vfio_fwd_irq_irq_node is used instead of having a list of devices and a list of forward irq per device. Having 2 lists brought extra complexity. - the VFIO device ref counter is incremented each time a new IRQ is forwarded. It is not attempted anymore to hold a single reference whatever the number of forwarded IRQs. - subindex added on top of index to be closer to VFIO API - platform device check moved in the arm specific implementation - enable the KVM-VFIO device for arm64 - forwarded state change only can happen while the VFIO IRQ handler is not set; in other words, when the VFIO IRQ signaling is not set. v1 -> v2: - forward control is moved from architecture specific file into generic vfio.c module. only kvm_arch_set_fwd_state remains architecture specific - integrate Kim's patch which enables KVM-VFIO for ARM - fix vgic state bypass in vgic_queue_hwirq - struct kvm_arch_forwarded_irq moved from arch/arm/include/uapi/asm/kvm.h to include/uapi/linux/kvm.h also irq_index renamed into index and guest_irq renamed into gsi - ASSIGN/DEASSIGN renamed into FORWARD/UNFORWARD - vfio_external_get_base_device renamed into vfio_external_base_device - vfio_external_get_type removed - kvm_vfio_external_get_base_device renamed into kvm_vfio_external_base_device - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD Eric Auger (7): KVM: arm64: Enable the KVM-VFIO device VFIO: platform: forwarded state tested when selecting IRQ handler KVM: kvm-vfio: User API for IRQ forwarding VFIO: External user API device helpers KVM: kvm-vfio: wrapper to VFIO external API device helpers KVM: kvm-vfio: generic forwarding control KVM: arm: kvm-vfio: forwarding control Kim Phillips (1): KVM: arm: Enable the KVM-VFIO device Documentation/virtual/kvm/devices/vfio.txt | 34 +++- arch/arm/include/asm/kvm_host.h| 7 + arch/arm/kvm/Kconfig | 1 + arch/arm/kvm/Makefile | 4 +- arch/arm/kvm/kvm_vfio_arm.c| 101 ++ arch/arm64/kvm/Kconfig
Re: nested KVM slower than QEMU with gnumach guest kernel
Jan Kiszka, le Mon 17 Nov 2014 10:04:37 +0100, a écrit : > On 2014-11-17 10:03, Samuel Thibault wrote: > > Gleb Natapov, le Mon 17 Nov 2014 10:58:45 +0200, a écrit : > >> Do you know how gnumach timekeeping works? Does it have a timer that fires > >> each 1ms? > >> Which clock device is it using? > > > > It uses the PIT every 10ms, in square mode > > (PIT_C0|PIT_SQUAREMODE|PIT_READMODE = 0x36). > > Wow... how retro. That feature might be unsupported (BTW, I tried the more common ndiv mode, 0x34, with the same result) Samuel -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nested KVM slower than QEMU with gnumach guest kernel
Jan Kiszka, le Mon 17 Nov 2014 07:28:23 +0100, a écrit : > I suppose this is a SMP host and guest? Does reducing CPUs to 1 change > to picture? Oddly enough, putting my host into UniProcessor mode is making L1 realmode simulation awfully slow. That also happens when binding kvm on a single hardware thread like this: hwloc-bind pu:0 kvm ... but not when binding kvm on the two threads of the same core like this: hwloc-bind core:0 kvm ... ... > > Here is a sample of trace-cmd output dump: the same kind of pattern > > repeats over and over, with EXTERNAL_INTERRUPT happening mostly > > every other microsecond: > > > > qemu-system-x86-9752 [003] 4106.187755: kvm_exit: reason > > EXTERNAL_INTERRUPT rip 0xa02848b1 info 0 80f6 > > qemu-system-x86-9752 [003] 4106.187756: kvm_entry:vcpu 0 > > qemu-system-x86-9752 [003] 4106.187757: kvm_exit: reason > > EXTERNAL_INTERRUPT rip 0xa02848b1 info 0 80f6 > > qemu-system-x86-9752 [003] 4106.187758: kvm_entry:vcpu 0 > > qemu-system-x86-9752 [003] 4106.187759: kvm_exit: reason > > EXTERNAL_INTERRUPT rip 0xa02848b1 info 0 80f6 > > qemu-system-x86-9752 [003] 4106.187760: kvm_entry:vcpu 0 Turning into UniProcessor mode however dropped them, but the slowness is still there. So they are probably actually not the source of the issue. I'm actually wondering whether they weren't simply coming from the tracing engine itself: I see some irq_work_queue calls from kernel/trace/ring_buffer.c and kernel/events/core.c. > You may want to turn on more trace events, if not all, to possibly see > what Linux does then. With the EXTERNAL_INTERRUPT mostly away, I mostly get this over and over: qemu-system-x86-2138 [000] 247.558705: kvm_exit: reason MSR_READ rip 0x81050a82 info 0 0 native_read_msr_safe qemu-system-x86-2138 [000] 247.558705: kvm_msr: msr_read 1d9 = 0x0 qemu-system-x86-2138 [000] 247.558705: rcu_utilization: Start context switch qemu-system-x86-2138 [000] 247.558706: rcu_utilization: End context switch qemu-system-x86-2138 [000] 247.558706: kvm_entry: vcpu 0 qemu-system-x86-2138 [000] 247.558706: kvm_exit: reason VMRESUME rip 0xa03058ae info 0 0 vmx_vcpu_run qemu-system-x86-2138 [000] 247.558711: kvm_mmu_get_page: [FAILED TO PARSE] mmu_valid_gen=0x26 gfn=248173 role=114692 root_count=0 unsync=0 created=0 qemu-system-x86-2138 [000] 247.558712: rcu_utilization: Start context switch qemu-system-x86-2138 [000] 247.558712: rcu_utilization: End context switch qemu-system-x86-2138 [000] 247.558712: kvm_entry: vcpu 0 qemu-system-x86-2138 [000] 247.558712: kvm_exit: reason IO_INSTRUCTION rip 0xc0109769 info a10040 0 gnumach accesses the PIC qemu-system-x86-2138 [000] 247.558713: kvm_nested_vmexit: rip: 0xc0109769 reason: IO_INSTRUCTION ext_inf1: 0x00a10040 ext_inf2: 0x ext_int: 0x ext_int_err: 0x qemu-system-x86-2138 [000] 247.558713: kvm_nested_vmexit_inject: reason: IO_INSTRUCTION ext_inf1: 0x00a10040 ext_inf2: 0x ext_int: 0x ext_int_err: 0x qemu-system-x86-2138 [000] 247.558718: kvm_mmu_get_page: [FAILED TO PARSE] mmu_valid_gen=0x26 gfn=0 role=122884 root_count=0 unsync=0 created=0 qemu-system-x86-2138 [000] 247.558718: rcu_utilization: Start context switch qemu-system-x86-2138 [000] 247.558719: rcu_utilization: End context switch qemu-system-x86-2138 [000] 247.558719: kvm_entry: vcpu 0 qemu-system-x86-2138 [000] 247.558719: kvm_exit: reason VMREAD rip 0xa0305956 info 0 0 vmx_vcpu_run qemu-system-x86-2138 [000] 247.558720: rcu_utilization: Start context switch qemu-system-x86-2138 [000] 247.558720: rcu_utilization: End context switch qemu-system-x86-2138 [000] 247.558720: kvm_entry: vcpu 0 qemu-system-x86-2138 [000] 247.558721: kvm_exit: reason VMREAD rip 0xa030596f info 0 0 vmx_vcpu_run qemu-system-x86-2138 [000] 247.558721: rcu_utilization: Start context switch qemu-system-x86-2138 [000] 247.558721: rcu_utilization: End context switch qemu-system-x86-2138 [000] 247.558721: kvm_entry: vcpu 0 qemu-system-x86-2138 [000] 247.558722: kvm_exit: reason VMREAD rip 0xa02fb333 info 0 0 vmx_read_l1_tsc qemu
Re: KVM causes #GP on XRSTORS
Hi Paolo, On Fri, Nov 21, 2014 at 03:46:55PM +0100, Paolo Bonzini wrote: > > >On 20/11/2014 17:34, Nadav Amit wrote: >> Fenghua, >> >> I got KVM (v3.17) crashing on a machine that supports XRSTORS - It appears >> to get a #GP when it is trying to load the guest FPU. >> One reason for the #GP is that XCOMP_BV[63] is zeroed on the guest_fpu, but >> I am not sure it is the only problem. >> Was KVM ever tested with XRSTORS? > >What is the content of the CPUID[EAX=13,ECX=0] and CPUID[EAX=13,ECX=1] >leaves on the host? > >Fenghua, which processors have XSAVEC, which have XGETBV with ECX=1, and >which have XSAVES? We need to expose this in QEMU, for which I can send Skylake-client supports XSAVES. >a patch later today or next week (CCing Eduardo for this). Actually I do the xsaves work in kvm/qemu recently and the patches are complete, I will start to test it before send out. Regards, Wanpeng Li > >We will also have to uncompact the XSAVE area either in KVM_GET_XSAVE or >in QEMU. It's probably not hard to do it in the kernel. > >Paolo >-- >To unsubscribe from this list: send the line "unsubscribe kvm" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CFT PATCH 2/2] KVM: x86: support XSAVES usage in the host
Hi Paolo,
On Fri, Nov 21, 2014 at 07:31:18PM +0100, Paolo Bonzini wrote:
[...]
>+ u64 feature = valid & -valid;
>+ int index = fls64(feature) - 1;
>+ void *src = get_xsave_addr(xsave, feature);
>+
>+ if (src) {
>+ u32 size, offset, ecx, edx;
>+ cpuid_count(XSTATE_CPUID, index,
>+ &size, &offset, &ecx, &edx);
>+ memcpy(dest + offset, src, size);
The offset you get is still for compact format, so you almost convert compat
format to compat format instead of convert compact format to standard format.
In addition, I think convert standard format to compact format should be
implemented in put path.
Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
