* [PATCH 7/9] kvm/x86: split ioapic-handled and EOI exit bitmaps
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
The function to determine if the vector is handled by ioapic used to
rely on the fact that only ioapic-handled vectors were set up to
cause vmexits when virtual apic was in use.
We're going to break this assumption when introducing Hyper-V
synthetic interrupts: they may need to cause vmexits too.
To achieve that, introduce a new bitmap dedicated specifically for
ioapic-handled vectors, and populate EOI exit bitmap from it for now.
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/include/asm/kvm_host.h | 4 ++--
arch/x86/kvm/ioapic.c | 4 ++--
arch/x86/kvm/ioapic.h | 7 ++++---
arch/x86/kvm/irq_comm.c | 6 +++---
arch/x86/kvm/lapic.c | 2 +-
arch/x86/kvm/svm.c | 2 +-
arch/x86/kvm/vmx.c | 3 +--
arch/x86/kvm/x86.c | 12 +++++++-----
8 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 53deb27..07f7cd7 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -400,7 +400,7 @@ struct kvm_vcpu_arch {
u64 efer;
u64 apic_base;
struct kvm_lapic *apic; /* kernel irqchip context */
- u64 eoi_exit_bitmap[4];
+ DECLARE_BITMAP(ioapic_handled_vectors, 256);
unsigned long apic_attention;
int32_t apic_arb_prio;
int mp_state;
@@ -833,7 +833,7 @@ struct kvm_x86_ops {
int (*cpu_uses_apicv)(struct kvm_vcpu *vcpu);
void (*hwapic_irr_update)(struct kvm_vcpu *vcpu, int max_irr);
void (*hwapic_isr_update)(struct kvm *kvm, int isr);
- void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);
+ void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
void (*set_virtual_x2apic_mode)(struct kvm_vcpu *vcpu, bool set);
void (*set_apic_access_page_addr)(struct kvm_vcpu *vcpu, hpa_t hpa);
void (*deliver_posted_interrupt)(struct kvm_vcpu *vcpu, int vector);
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 2dcda0f..3cf7a9c 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -233,7 +233,7 @@ static void kvm_ioapic_inject_all(struct kvm_ioapic *ioapic, unsigned long irr)
}
-void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
+void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, ulong *ioapic_handled_vectors)
{
struct kvm_ioapic *ioapic = vcpu->kvm->arch.vioapic;
union kvm_ioapic_redirect_entry *e;
@@ -248,7 +248,7 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
if (kvm_apic_match_dest(vcpu, NULL, 0,
e->fields.dest_id, e->fields.dest_mode))
__set_bit(e->fields.vector,
- (unsigned long *)eoi_exit_bitmap);
+ ioapic_handled_vectors);
}
}
spin_unlock(&ioapic->lock);
diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
index 084617d..2d16dc2 100644
--- a/arch/x86/kvm/ioapic.h
+++ b/arch/x86/kvm/ioapic.h
@@ -121,7 +121,8 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct kvm_lapic *src,
struct kvm_lapic_irq *irq, unsigned long *dest_map);
int kvm_get_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
-void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
-void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
-
+void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu,
+ ulong *ioapic_handled_vectors);
+void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu,
+ ulong *ioapic_handled_vectors);
#endif
diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
index 6f922c2..fe91f72 100644
--- a/arch/x86/kvm/irq_comm.c
+++ b/arch/x86/kvm/irq_comm.c
@@ -371,7 +371,8 @@ void kvm_arch_post_irq_routing_update(struct kvm *kvm)
kvm_make_scan_ioapic_request(kvm);
}
-void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
+void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu,
+ ulong *ioapic_handled_vectors)
{
struct kvm *kvm = vcpu->kvm;
struct kvm_kernel_irq_routing_entry *entry;
@@ -398,8 +399,7 @@ void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
dest_mode)) {
u32 vector = entry->msi.data & 0xff;
- __set_bit(vector,
- (unsigned long *) eoi_exit_bitmap);
+ __set_bit(vector, ioapic_handled_vectors);
}
}
}
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 944b38a..dc03a01 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -930,7 +930,7 @@ int kvm_apic_compare_prio(struct kvm_vcpu *vcpu1, struct kvm_vcpu *vcpu2)
static bool kvm_ioapic_handles_vector(struct kvm_lapic *apic, int vector)
{
- return test_bit(vector, (ulong *)apic->vcpu->arch.eoi_exit_bitmap);
+ return test_bit(vector, apic->vcpu->arch.ioapic_handled_vectors);
}
static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 54a8618..03ccb78 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3651,7 +3651,7 @@ static int svm_cpu_uses_apicv(struct kvm_vcpu *vcpu)
return 0;
}
-static void svm_load_eoi_exitmap(struct kvm_vcpu *vcpu)
+static void svm_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
{
return;
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8eeba6a..fccf39c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8179,9 +8179,8 @@ static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu, int max_irr)
}
}
-static void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu)
+static void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
{
- u64 *eoi_exit_bitmap = vcpu->arch.eoi_exit_bitmap;
if (!vmx_cpu_uses_apicv(vcpu))
return;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bcbc9234..668a1c4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6198,13 +6198,15 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
if (!kvm_apic_hw_enabled(vcpu->arch.apic))
return;
- memset(vcpu->arch.eoi_exit_bitmap, 0, 256 / 8);
+ bitmap_zero(vcpu->arch.ioapic_handled_vectors, 256);
if (irqchip_split(vcpu->kvm))
- kvm_scan_ioapic_routes(vcpu, vcpu->arch.eoi_exit_bitmap);
+ kvm_scan_ioapic_routes(vcpu, vcpu->arch.ioapic_handled_vectors);
else
- kvm_ioapic_scan_entry(vcpu, vcpu->arch.eoi_exit_bitmap);
- kvm_x86_ops->load_eoi_exitmap(vcpu);
+ kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
+
+ kvm_x86_ops->load_eoi_exitmap(vcpu,
+ (u64 *)vcpu->arch.ioapic_handled_vectors);
}
static void kvm_vcpu_flush_tlb(struct kvm_vcpu *vcpu)
@@ -6310,7 +6312,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
if (kvm_check_request(KVM_REQ_IOAPIC_EOI_EXIT, vcpu)) {
BUG_ON(vcpu->arch.pending_ioapic_eoi > 255);
if (test_bit(vcpu->arch.pending_ioapic_eoi,
- (void *) vcpu->arch.eoi_exit_bitmap)) {
+ vcpu->arch.ioapic_handled_vectors)) {
vcpu->run->exit_reason = KVM_EXIT_IOAPIC_EOI;
vcpu->run->eoi.vector =
vcpu->arch.pending_ioapic_eoi;
--
2.1.4
^ permalink raw reply related
* [PATCH 6/9] drivers/hv: share Hyper-V SynIC constants with userspace
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
Moved Hyper-V synic contants from guest Hyper-V drivers private
header into x86 arch uapi Hyper-V header.
Added Hyper-V synic msr's flags into x86 arch uapi Hyper-V header.
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/include/uapi/asm/hyperv.h | 12 ++++++++++++
drivers/hv/hyperv_vmbus.h | 5 -----
include/linux/hyperv.h | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h
index 2677a0a..040d408 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -257,4 +257,16 @@ typedef struct _HV_REFERENCE_TSC_PAGE {
__s64 tsc_offset;
} HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
+/* Define the number of synthetic interrupt sources. */
+#define HV_SYNIC_SINT_COUNT (16)
+/* Define the expected SynIC version. */
+#define HV_SYNIC_VERSION_1 (0x1)
+
+#define HV_SYNIC_CONTROL_ENABLE (1ULL << 0)
+#define HV_SYNIC_SIMP_ENABLE (1ULL << 0)
+#define HV_SYNIC_SIEFP_ENABLE (1ULL << 0)
+#define HV_SYNIC_SINT_MASKED (1ULL << 16)
+#define HV_SYNIC_SINT_AUTO_EOI (1ULL << 17)
+#define HV_SYNIC_SINT_VECTOR_MASK (0xFF)
+
#endif
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3d70e36..3782636 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -63,9 +63,6 @@ enum hv_cpuid_function {
/* Define version of the synthetic interrupt controller. */
#define HV_SYNIC_VERSION (1)
-/* Define the expected SynIC version. */
-#define HV_SYNIC_VERSION_1 (0x1)
-
/* Define synthetic interrupt controller message constants. */
#define HV_MESSAGE_SIZE (256)
#define HV_MESSAGE_PAYLOAD_BYTE_COUNT (240)
@@ -105,8 +102,6 @@ enum hv_message_type {
HVMSG_X64_LEGACY_FP_ERROR = 0x80010005
};
-/* Define the number of synthetic interrupt sources. */
-#define HV_SYNIC_SINT_COUNT (16)
#define HV_SYNIC_STIMER_COUNT (4)
/* Define invalid partition identifier. */
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 54733d5..8fdc17b 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -26,6 +26,7 @@
#define _HYPERV_H
#include <uapi/linux/hyperv.h>
+#include <uapi/asm/hyperv.h>
#include <linux/types.h>
#include <linux/scatterlist.h>
--
2.1.4
^ permalink raw reply related
* [PATCH 5/9] kvm/irqchip: kvm_arch_irq_routing_update renaming split
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
Actually kvm_arch_irq_routing_update() should be
kvm_arch_post_irq_routing_update() as it's called at the end
of irq routing update.
This renaming frees kvm_arch_irq_routing_update function name.
kvm_arch_irq_routing_update() weak function which will be used
to update mappings for arch-specific irq routing entries
(in particular, the upcoming Hyper-V synthetic interrupts).
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/irq_comm.c | 2 +-
include/linux/kvm_host.h | 5 +++--
virt/kvm/irqchip.c | 7 ++++++-
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
index c892289..6f922c2 100644
--- a/arch/x86/kvm/irq_comm.c
+++ b/arch/x86/kvm/irq_comm.c
@@ -364,7 +364,7 @@ int kvm_setup_empty_irq_routing(struct kvm *kvm)
return kvm_set_irq_routing(kvm, empty_routing, 0, 0);
}
-void kvm_arch_irq_routing_update(struct kvm *kvm)
+void kvm_arch_post_irq_routing_update(struct kvm *kvm)
{
if (ioapic_in_kernel(kvm) || !irqchip_in_kernel(kvm))
return;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index eba9cae..c742e79 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -473,12 +473,12 @@ void vcpu_put(struct kvm_vcpu *vcpu);
#ifdef __KVM_HAVE_IOAPIC
void kvm_vcpu_request_scan_ioapic(struct kvm *kvm);
-void kvm_arch_irq_routing_update(struct kvm *kvm);
+void kvm_arch_post_irq_routing_update(struct kvm *kvm);
#else
static inline void kvm_vcpu_request_scan_ioapic(struct kvm *kvm)
{
}
-static inline void kvm_arch_irq_routing_update(struct kvm *kvm)
+static inline void kvm_arch_post_irq_routing_update(struct kvm *kvm)
{
}
#endif
@@ -1080,6 +1080,7 @@ static inline void kvm_irq_routing_update(struct kvm *kvm)
{
}
#endif
+void kvm_arch_irq_routing_update(struct kvm *kvm);
static inline int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
{
diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
index f0b08a2..fe84e1a 100644
--- a/virt/kvm/irqchip.c
+++ b/virt/kvm/irqchip.c
@@ -166,6 +166,10 @@ out:
return r;
}
+void __attribute__((weak)) kvm_arch_irq_routing_update(struct kvm *kvm)
+{
+}
+
int kvm_set_irq_routing(struct kvm *kvm,
const struct kvm_irq_routing_entry *ue,
unsigned nr,
@@ -219,9 +223,10 @@ int kvm_set_irq_routing(struct kvm *kvm,
old = kvm->irq_routing;
rcu_assign_pointer(kvm->irq_routing, new);
kvm_irq_routing_update(kvm);
+ kvm_arch_irq_routing_update(kvm);
mutex_unlock(&kvm->irq_lock);
- kvm_arch_irq_routing_update(kvm);
+ kvm_arch_post_irq_routing_update(kvm);
synchronize_srcu_expedited(&kvm->irq_srcu);
--
2.1.4
^ permalink raw reply related
* [PATCH 4/9] kvm/irqchip: allow only multiple irqchip routes per GSI
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
Any other irq routing types (MSI, S390_ADAPTER, upcoming Hyper-V
SynIC) map one-to-one to GSI.
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
virt/kvm/irqchip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
index 716a1c4..f0b08a2 100644
--- a/virt/kvm/irqchip.c
+++ b/virt/kvm/irqchip.c
@@ -144,11 +144,11 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt,
/*
* Do not allow GSI to be mapped to the same irqchip more than once.
- * Allow only one to one mapping between GSI and MSI.
+ * Allow only one to one mapping between GSI and non-irqchip routing.
*/
hlist_for_each_entry(ei, &rt->map[ue->gsi], link)
- if (ei->type == KVM_IRQ_ROUTING_MSI ||
- ue->type == KVM_IRQ_ROUTING_MSI ||
+ if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
+ ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
ue->u.irqchip.irqchip == ei->irqchip.irqchip)
return r;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/9] kvm/eventfd: add arch-specific set_irq
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
Allow for arch-specific interrupt types to be set. For that, add
kvm_arch_set_irq() which takes interrupt type-specific action if it
recognizes the interrupt type given, and -EWOULDBLOCK otherwise.
The default implementation always returns -EWOULDBLOCK.
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/kvm_host.h | 4 ++++
virt/kvm/eventfd.c | 13 ++++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index b66861c..eba9cae 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -828,6 +828,10 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level,
int kvm_set_irq_inatomic(struct kvm *kvm, int irq_source_id, u32 irq, int level);
int kvm_set_msi(struct kvm_kernel_irq_routing_entry *irq_entry, struct kvm *kvm,
int irq_source_id, int level, bool line_status);
+
+int kvm_arch_set_irq(struct kvm_kernel_irq_routing_entry *irq, struct kvm *kvm,
+ int irq_source_id, int level, bool line_status);
+
bool kvm_irq_has_notifier(struct kvm *kvm, unsigned irqchip, unsigned pin);
void kvm_notify_acked_gsi(struct kvm *kvm, int gsi);
void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin);
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index f6b986a..e29fd26 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -171,6 +171,15 @@ irqfd_deactivate(struct kvm_kernel_irqfd *irqfd)
queue_work(irqfd_cleanup_wq, &irqfd->shutdown);
}
+int __attribute__((weak)) kvm_arch_set_irq(
+ struct kvm_kernel_irq_routing_entry *irq,
+ struct kvm *kvm, int irq_source_id,
+ int level,
+ bool line_status)
+{
+ return -EWOULDBLOCK;
+}
+
/*
* Called with wqh->lock held and interrupts disabled
*/
@@ -195,7 +204,9 @@ irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
if (irq.type == KVM_IRQ_ROUTING_MSI)
kvm_set_msi(&irq, kvm, KVM_USERSPACE_IRQ_SOURCE_ID, 1,
false);
- else
+ else if (kvm_arch_set_irq(&irq, kvm,
+ KVM_USERSPACE_IRQ_SOURCE_ID, 1,
+ false) == -EWOULDBLOCK)
schedule_work(&irqfd->inject);
srcu_read_unlock(&kvm->irq_srcu, idx);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 2/9] kvm/eventfd: factor out kvm_notify_acked_gsi()
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
Factor out kvm_notify_acked_gsi() helper to iterate over EOI listeners
and notify those matching the given gsi.
It will be reused in the upcoming Hyper-V SynIC implementation.
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
include/linux/kvm_host.h | 1 +
virt/kvm/eventfd.c | 16 +++++++++++-----
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9596a2f..b66861c 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -829,6 +829,7 @@ int kvm_set_irq_inatomic(struct kvm *kvm, int irq_source_id, u32 irq, int level)
int kvm_set_msi(struct kvm_kernel_irq_routing_entry *irq_entry, struct kvm *kvm,
int irq_source_id, int level, bool line_status);
bool kvm_irq_has_notifier(struct kvm *kvm, unsigned irqchip, unsigned pin);
+void kvm_notify_acked_gsi(struct kvm *kvm, int gsi);
void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin);
void kvm_register_irq_ack_notifier(struct kvm *kvm,
struct kvm_irq_ack_notifier *kian);
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 518421e..f6b986a 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -451,9 +451,18 @@ bool kvm_irq_has_notifier(struct kvm *kvm, unsigned irqchip, unsigned pin)
}
EXPORT_SYMBOL_GPL(kvm_irq_has_notifier);
-void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
+void kvm_notify_acked_gsi(struct kvm *kvm, int gsi)
{
struct kvm_irq_ack_notifier *kian;
+
+ hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
+ link)
+ if (kian->gsi == gsi)
+ kian->irq_acked(kian);
+}
+
+void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
+{
int gsi, idx;
trace_kvm_ack_irq(irqchip, pin);
@@ -461,10 +470,7 @@ void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
idx = srcu_read_lock(&kvm->irq_srcu);
gsi = kvm_irq_map_chip_pin(kvm, irqchip, pin);
if (gsi != -1)
- hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
- link)
- if (kian->gsi == gsi)
- kian->irq_acked(kian);
+ kvm_notify_acked_gsi(kvm, gsi);
srcu_read_unlock(&kvm->irq_srcu, idx);
}
--
2.1.4
^ permalink raw reply related
* [PATCH 1/9] kvm/eventfd: avoid loop inside irqfd_update()
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1444979273-6587-1-git-send-email-den@openvz.org>
From: Andrey Smetanin <asmetanin@virtuozzo.com>
The loop(for) inside irqfd_update() is unnecessary
because any other value for irq_entry.type will just trigger
schedule_work(&irqfd->inject).
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
---
virt/kvm/eventfd.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index b637965..518421e 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -238,20 +238,17 @@ static void irqfd_update(struct kvm *kvm, struct kvm_kernel_irqfd *irqfd)
{
struct kvm_kernel_irq_routing_entry *e;
struct kvm_kernel_irq_routing_entry entries[KVM_NR_IRQCHIPS];
- int i, n_entries;
+ int n_entries;
n_entries = kvm_irq_map_gsi(kvm, entries, irqfd->gsi);
write_seqcount_begin(&irqfd->irq_entry_sc);
- irqfd->irq_entry.type = 0;
-
e = entries;
- for (i = 0; i < n_entries; ++i, ++e) {
- /* Only fast-path MSI. */
- if (e->type == KVM_IRQ_ROUTING_MSI)
- irqfd->irq_entry = *e;
- }
+ if (n_entries == 1)
+ irqfd->irq_entry = *e;
+ else
+ irqfd->irq_entry.type = 0;
write_seqcount_end(&irqfd->irq_entry_sc);
}
--
2.1.4
^ permalink raw reply related
* [PATCH v2 0/9] Hyper-V synthetic interrupt controller
From: Denis V. Lunev @ 2015-10-16 7:07 UTC (permalink / raw)
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, rkagan,
Paolo Bonzini, Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
This patchset implements the KVM part of the synthetic interrupt
controller (SynIC) which is a building block of the Hyper-V
paravirtualized device bus (vmbus).
SynIC is a lapic extension, which is controlled via MSRs and maintains
for each vCPU
- 16 synthetic interrupt "lines" (SINT's); each can be configured to
trigger a specific interrupt vector optionally with auto-EOI
semantics
- a message page in the guest memory with 16 256-byte per-SINT message
slots
- an event flag page in the guest memory with 16 2048-bit per-SINT
event flag areas
The host triggers a SINT whenever it delivers a new message to the
corresponding slot or flips an event flag bit in the corresponding area.
The guest informs the host that it can try delivering a message by
explicitly asserting EOI in lapic or writing to End-Of-Message (EOM)
MSR.
The userspace (qemu) triggers interrupts and receives EOM notifications
via irqfd with resampler; for that, a GSI is allocated for each
configured SINT, and irq_routing api is extended to support GSI-SINT
mapping.
Besides, a new vcpu exit is introduced to notify the userspace of the
changes in SynIC configuraion triggered by guest writing to the
corresponding MSRs.
Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "K. Y. Srinivasan" <kys@microsoft.com>
CC: Gleb Natapov <gleb@kernel.org>
CC: Paolo Bonzini <pbonzini@redhat.com>
Changes v2:
* irqchip/eventfd preparation improvements to support
arch specific routing entries like Hyper-V SynIC ones.
* add Hyper-V SynIC vectors into EOI exit bitmap.
* do not use posted interrupts in case of Hyper-V SynIC
AutoEOI vectors
^ permalink raw reply
* Call for Papers - WorldCIST'16 - 4th World Conference on Information Systems and Technologies
From: Maria Lemos @ 2015-10-13 14:38 UTC (permalink / raw)
To: virtualization
[-- Attachment #1: Type: text/plain, Size: 7213 bytes --]
--
-- We apologise for any cross-posting.
--
---- Please forward for your contacts. Thank you so much!
--
---------
WorldCIST'16 - 4th World Conference on Information Systems and Technologies
Recife, PE, Brazil
22th-24th of March 2016
http://www.aisti.eu/worldcist16/
-------------------------------------------
SCOPE
The WorldCist'16 - 4th World Conference on Information Systems and Technologies, to be held at Recife, PE, Brazil, 22 - 24 March 2016, is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.
We are pleased to invite you to submit your papers to WorldCist'16. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
THEMES
Submitted papers should be related with one or more of the main themes proposed for the Conference:
A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Health Informatics (HIS);
K) Information Technologies in Education (ITE);
L) Information Technologies in Radiocommunications (ITR).
TYPES OF SUBMISSIONS AND DECISIONS
Four types of papers can be submitted:
- Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.
- Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.
-Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.
- Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.
Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see Instructions for Authors at Springer Website or download a DOC example) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version, saved in Word or Latex format and also in PDF format. These files must be accompanied by the Consent to Publication form filled out, in a ZIP file, and uploaded at the conference management system.
All papers will be subjected to a “double-blind review” by at least two members of the Program Committee.
Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.
The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.
The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.
PUBLICATION AND INDEXING
To ensure that a full paper, short paper, poster paper or company paper is published in the Proceedings, at least one of the authors must be fully registered by the 27th of December 2015, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published in the Conference Proceedings. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration.
Full and short papers will be published in Proceedings by Springer, in a book of Advances in Intelligent Systems and Computing series. Poster and company papers will be published by AISTI.
Published full and short papers will be submitted for indexation by ISI, EI-Compendex, SCOPUS and DBLP, among others, and will be available in the SpringerLink Digital Library.
The authors of the best selected papers will be invited to extend them for publication in international journals indexed by ISI/SCI, SCOPUS and DBLP, among others, such as:
- International Journal of Neural Systems (IF: 6.507)
- Integrated Computer-Aided Engineering (IF: 4.698)
- Computers in Human Behavior (IF: 2.694)
- Journal of Medical Systems (IF: 2.213)
- International Journal of Computer-Supported Collaborative Learning (IF: 1.841)
- Journal of Intelligent & Fuzzy Systems (IF: 1.812)
- Telemedicine and e-Health (IF: 1.668)
- International Journal of Information Management (IF: 1.550)
- Engineering Computations (IF: 1.495)
- Electronic Commerce Research and Applications (IF: 1.482)
- Telematics and Informatics (IF: 1.120)
- Journal of Evaluation in Clinical Practice (IF: 1.084)
- Ethics and Information Technology (IF: 1.021)
- Int. Journal of Computers Communications & Control (IF: 0.746)
- IET Software (IF: 0.595)
- Knowledge Management Research & Practice (IF: 0.554)
- AI Communications (IF: 0.547)
- Computing and Informatics (IF: 0.504)
- Universal Access in the Information Society (IF: 0.475)
- Journal of Global Information Management (IF: 0.424)
- Journal of Internet Services and Applications (SJR: 0.88)
- Journal of Hospitality and Tourism Technology (SJR: 0.41)
- VINE - The Journal of Information and Knowledge Management Systems (SJR: 0.24)
- International Journal of Online Engineering (SJR: 0.21)
- Int. Journal of Emerging Technologies in Learning (SJR: 0.12)
- Computer Methods in Biomechanics and Biomedical Engineering: Imaging & Visualization
IMPORTANT DATES
Paper Submission: November 8, 2015
Notification of Acceptance: December 13, 2015
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: December 27, 2015.
Camera-ready Submission: December 31, 2015
-
WorldCIST'16
http://www.aisti.eu/worldcist16/
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* RE: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: KY Srinivasan @ 2015-10-12 22:21 UTC (permalink / raw)
To: Denis V. Lunev, Eric Blake
Cc: Gleb Natapov, qemu-devel@nongnu.org,
virtualization@lists.linux-foundation.org, rkagan@virtuozzo.com,
Andrey Smetanin, Paolo Bonzini, Vitaly Kuznetsov
In-Reply-To: <561BB9A9.2070102@openvz.org>
> -----Original Message-----
> From: Denis V. Lunev [mailto:den@openvz.org]
> Sent: Monday, October 12, 2015 6:46 AM
> To: Eric Blake <eblake@redhat.com>
> Cc: Gleb Natapov <gleb@kernel.org>; qemu-devel@nongnu.org;
> virtualization@lists.linux-foundation.org; rkagan@virtuozzo.com; Paolo
> Bonzini <pbonzini@redhat.com>; Andrey Smetanin
> <asmetanin@virtuozzo.com>; Vitaly Kuznetsov <vkuznets@redhat.com>; KY
> Srinivasan <kys@microsoft.com>
> Subject: Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
>
> On 10/12/2015 04:42 PM, Eric Blake wrote:
> > On 10/09/2015 07:39 AM, Denis V. Lunev wrote:
> >> From: Andrey Smetanin <asmetanin@virtuozzo.com>
> >>
> >> A new vcpu exit is introduced to notify the userspace of the
> >> changes in Hyper-V synic configuraion triggered by guest writing to the
> > s/configuraion/configuration/
> > Is 'synic' intended? Is it short for something (if so, spelling it out
> > may help)?
> >
> >
> >> +++ b/Documentation/virtual/kvm/api.txt
> >> @@ -3331,6 +3331,12 @@ the userspace IOAPIC should process the EOI
> and retrigger the interrupt if
> >> it is still asserted. Vector is the LAPIC interrupt vector for which the
> >> EOI was received.
> >>
> >> + /* KVM_EXIT_HYPERV */
> >> + struct kvm_hyperv_exit hyperv;
> >> +Indicates that the VCPU's exits into userspace to process some tasks
> > s/VCPU's/VCPU/
> >
> >> +related with Hyper-V emulation. Currently used to synchronize modified
> >> +Hyper-V synic state with userspace.
> > Again, is 'synic' intended? Hmm, I see it throughout the patch, so it
> > looks intentional, but I keep trying to read it as a typo for 'sync'.
> >
> this is not a typo :)
Yes; the Hyper-V public functional spec has chosen this name;
it stands for Synthetic Interrupt Controller.
K. Y
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Roman Kagan @ 2015-10-12 13:52 UTC (permalink / raw)
To: Eric Blake
Cc: Gleb Natapov, qemu-devel, virtualization, Paolo Bonzini,
Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <561BB8D2.60402@redhat.com>
On Mon, Oct 12, 2015 at 07:42:42AM -0600, Eric Blake wrote:
> On 10/09/2015 07:39 AM, Denis V. Lunev wrote:
> > From: Andrey Smetanin <asmetanin@virtuozzo.com>
> >
> > A new vcpu exit is introduced to notify the userspace of the
> > changes in Hyper-V synic configuraion triggered by guest writing to the
> Again, is 'synic' intended? Hmm, I see it throughout the patch, so it
> looks intentional, but I keep trying to read it as a typo for 'sync'.
I tend to mistype it as 'cynic' as better matching what it is ;)
Note taken, we'll address that in the next round, thanks.
Roman.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Denis V. Lunev @ 2015-10-12 13:46 UTC (permalink / raw)
To: Eric Blake
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Paolo Bonzini, Vitaly Kuznetsov
In-Reply-To: <561BB8D2.60402@redhat.com>
On 10/12/2015 04:42 PM, Eric Blake wrote:
> On 10/09/2015 07:39 AM, Denis V. Lunev wrote:
>> From: Andrey Smetanin <asmetanin@virtuozzo.com>
>>
>> A new vcpu exit is introduced to notify the userspace of the
>> changes in Hyper-V synic configuraion triggered by guest writing to the
> s/configuraion/configuration/
> Is 'synic' intended? Is it short for something (if so, spelling it out
> may help)?
>
>
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -3331,6 +3331,12 @@ the userspace IOAPIC should process the EOI and retrigger the interrupt if
>> it is still asserted. Vector is the LAPIC interrupt vector for which the
>> EOI was received.
>>
>> + /* KVM_EXIT_HYPERV */
>> + struct kvm_hyperv_exit hyperv;
>> +Indicates that the VCPU's exits into userspace to process some tasks
> s/VCPU's/VCPU/
>
>> +related with Hyper-V emulation. Currently used to synchronize modified
>> +Hyper-V synic state with userspace.
> Again, is 'synic' intended? Hmm, I see it throughout the patch, so it
> looks intentional, but I keep trying to read it as a typo for 'sync'.
>
this is not a typo :)
this is an abbreviation for synthetic interrupt controller,
pls compare with this
./arch/x86/include/uapi/asm/hyperv.h: * Basic SynIC MSRs
(HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
Though there is some sense in the question itself. I think
that it would be better to keep naming it SynIC as
in the original kernel code.
Den
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Paolo Bonzini @ 2015-10-12 13:46 UTC (permalink / raw)
To: Eric Blake, Denis V. Lunev
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Vitaly Kuznetsov
In-Reply-To: <561BB8D2.60402@redhat.com>
On 12/10/2015 15:42, Eric Blake wrote:
> > +related with Hyper-V emulation. Currently used to synchronize modified
> > +Hyper-V synic state with userspace.
>
> Again, is 'synic' intended? Hmm, I see it throughout the patch, so it
> looks intentional, but I keep trying to read it as a typo for 'sync'.
It's synthetic interrupt controller, but indeed it's a bit obscure.
Perhaps we can change it in the docs to "Hyper-V synthetic interrupt state".
Paolo
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Eric Blake @ 2015-10-12 13:44 UTC (permalink / raw)
To: Denis V. Lunev
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Paolo Bonzini, Vitaly Kuznetsov
In-Reply-To: <561BB8D2.60402@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]
On 10/12/2015 07:42 AM, Eric Blake wrote:
> On 10/09/2015 07:39 AM, Denis V. Lunev wrote:
>> From: Andrey Smetanin <asmetanin@virtuozzo.com>
>>
>> A new vcpu exit is introduced to notify the userspace of the
>> changes in Hyper-V synic configuraion triggered by guest writing to the
>
> s/configuraion/configuration/
> Is 'synic' intended? Is it short for something (if so, spelling it out
> may help)?
Ah, I see it now from patch 1/2: SYNthetic Interrupt Controller.
>> +related with Hyper-V emulation. Currently used to synchronize modified
>> +Hyper-V synic state with userspace.
>
> Again, is 'synic' intended? Hmm, I see it throughout the patch, so it
> looks intentional, but I keep trying to read it as a typo for 'sync'.
Don't know if SynIC would make it any easier to read?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Eric Blake @ 2015-10-12 13:42 UTC (permalink / raw)
To: Denis V. Lunev
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Paolo Bonzini, Vitaly Kuznetsov
In-Reply-To: <1444397988-20167-3-git-send-email-den@openvz.org>
[-- Attachment #1.1: Type: text/plain, Size: 1155 bytes --]
On 10/09/2015 07:39 AM, Denis V. Lunev wrote:
> From: Andrey Smetanin <asmetanin@virtuozzo.com>
>
> A new vcpu exit is introduced to notify the userspace of the
> changes in Hyper-V synic configuraion triggered by guest writing to the
s/configuraion/configuration/
Is 'synic' intended? Is it short for something (if so, spelling it out
may help)?
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3331,6 +3331,12 @@ the userspace IOAPIC should process the EOI and retrigger the interrupt if
> it is still asserted. Vector is the LAPIC interrupt vector for which the
> EOI was received.
>
> + /* KVM_EXIT_HYPERV */
> + struct kvm_hyperv_exit hyperv;
> +Indicates that the VCPU's exits into userspace to process some tasks
s/VCPU's/VCPU/
> +related with Hyper-V emulation. Currently used to synchronize modified
> +Hyper-V synic state with userspace.
Again, is 'synic' intended? Hmm, I see it throughout the patch, so it
looks intentional, but I keep trying to read it as a typo for 'sync'.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Roman Kagan @ 2015-10-12 11:05 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Gleb Natapov, Andrey Smetanin, qemu-devel, virtualization,
Christian Borntraeger, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <561B763C.9050907@redhat.com>
On Mon, Oct 12, 2015 at 10:58:36AM +0200, Paolo Bonzini wrote:
> On 12/10/2015 10:48, Cornelia Huck wrote:
> > Going back to Paolo's original question, I think changing the check
> > to !KVM_IRQ_ROUTING_IRQCHIP makes sense, if I understand the code
> > correctly. They seem to be the only special one.
>
> Great. Roman, Denis, can you do this then?
Sure, gonna be in the next round.
Thanks,
Roman.
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Paolo Bonzini @ 2015-10-12 8:58 UTC (permalink / raw)
To: Cornelia Huck, Christian Borntraeger
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <20151012104848.396407b9.cornelia.huck@de.ibm.com>
On 12/10/2015 10:48, Cornelia Huck wrote:
> Going back to Paolo's original question, I think changing the check
> to !KVM_IRQ_ROUTING_IRQCHIP makes sense, if I understand the code
> correctly. They seem to be the only special one.
Great. Roman, Denis, can you do this then?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Cornelia Huck @ 2015-10-12 8:48 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Denis V. Lunev,
Andrey Smetanin, Paolo Bonzini, Vitaly Kuznetsov
In-Reply-To: <561B6741.8080309@de.ibm.com>
On Mon, 12 Oct 2015 09:54:41 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> Am 09.10.2015 um 16:42 schrieb Paolo Bonzini:
> > Christian, the question for you is towards the end...
>
>
>
> [....]
> >
> >> --- a/virt/kvm/irqchip.c
> >> +++ b/virt/kvm/irqchip.c
> >> @@ -144,11 +144,13 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt,
> >>
> >> /*
> >> * Do not allow GSI to be mapped to the same irqchip more than once.
> >> - * Allow only one to one mapping between GSI and MSI.
> >> + * Allow only one to one mapping between GSI and MSI/Hyper-V SINT.
> >> */
> >> hlist_for_each_entry(ei, &rt->map[ue->gsi], link)
> >> if (ei->type == KVM_IRQ_ROUTING_MSI ||
> >> ue->type == KVM_IRQ_ROUTING_MSI ||
> >> + ei->type == KVM_IRQ_ROUTING_HV_SINT ||
> >> + ue->type == KVM_IRQ_ROUTING_HV_SINT ||
> >> ue->u.irqchip.irqchip == ei->irqchip.irqchip)
> >> return r;
> >
> > Christian, what's the desired behavior for s390 adapter interrupts here?
> > Should this actually become
> >
> > if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
> > ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
> > ue->u.irqchip.irqchip == ei->irqchip.irqchip)
>
> Hmm, this is the failure path if we already have one routing entry, Right?
> This will work with virtio ccw as we only setup one route, but I am not
> sure about the upcoming PCI irqfd support which might add a 2nd adapter
> route.
>
> Adding Conny, Jens,Not sure about PC,
> As soon as we wire up the PCI irgfd, we want to register a 2nd route for
> the same irqchip via flic, which will also be of type
> KVM_IRQ_ROUTING_S390_ADAPTER. Correct?
It's a bit different. The kernel basically does not see msi routes for
s390 pci at all, as qemu already transforms the msi route into an
adapter route before registering it (see kvm_arch_fixup_msi_route() in
qemu's target-s390x/kvm.c). So, in the end, all s390 kernels end up
using adapter routes, and none of them are duplicate (just one irqchip).
Going back to Paolo's original question, I think changing the check
to !KVM_IRQ_ROUTING_IRQCHIP makes sense, if I understand the code
correctly. They seem to be the only special one.
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Christian Borntraeger @ 2015-10-12 7:54 UTC (permalink / raw)
To: Paolo Bonzini, Denis V. Lunev
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Vitaly Kuznetsov
In-Reply-To: <5617D259.8070101@redhat.com>
Am 09.10.2015 um 16:42 schrieb Paolo Bonzini:
> Christian, the question for you is towards the end...
[....]
>
>> --- a/virt/kvm/irqchip.c
>> +++ b/virt/kvm/irqchip.c
>> @@ -144,11 +144,13 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt,
>>
>> /*
>> * Do not allow GSI to be mapped to the same irqchip more than once.
>> - * Allow only one to one mapping between GSI and MSI.
>> + * Allow only one to one mapping between GSI and MSI/Hyper-V SINT.
>> */
>> hlist_for_each_entry(ei, &rt->map[ue->gsi], link)
>> if (ei->type == KVM_IRQ_ROUTING_MSI ||
>> ue->type == KVM_IRQ_ROUTING_MSI ||
>> + ei->type == KVM_IRQ_ROUTING_HV_SINT ||
>> + ue->type == KVM_IRQ_ROUTING_HV_SINT ||
>> ue->u.irqchip.irqchip == ei->irqchip.irqchip)
>> return r;
>
> Christian, what's the desired behavior for s390 adapter interrupts here?
> Should this actually become
>
> if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
> ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
> ue->u.irqchip.irqchip == ei->irqchip.irqchip)
Hmm, this is the failure path if we already have one routing entry, Right?
This will work with virtio ccw as we only setup one route, but I am not
sure about the upcoming PCI irqfd support which might add a 2nd adapter
route.
Adding Conny, Jens,Not sure about PC,
As soon as we wire up the PCI irgfd, we want to register a 2nd route for
the same irqchip via flic, which will also be of type
KVM_IRQ_ROUTING_S390_ADAPTER. Correct?
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Paolo Bonzini @ 2015-10-09 15:58 UTC (permalink / raw)
To: Roman Kagan, Denis V. Lunev, virtualization, qemu-devel,
Andrey Smetanin, Vitaly Kuznetsov, K. Y. Srinivasan, Gleb Natapov,
Christian Borntraeger
In-Reply-To: <20151009155307.GU27239@rkaganb.sw.ru>
On 09/10/2015 17:53, Roman Kagan wrote:
> > I really don't like this auto-EOI extension, but I guess that's the
> > spec. :( If it wasn't for it, you could do everything very easily in
> > userspace using Google's proposed MSR exit.
> I guess you're right. We'd probably have to (ab)use MSI for SINT
> delivery, though.
Not really an issue, as MSI on x86 is really just the external entry
point into the LAPIC, it makes sense that it be the external interface
into KVM's virtualized LAPIC. Userspace split irqchip is (ab)using MSI
routes the same way.
> Anyway the need to implement auto-EOI rules that out.
Yup. I look forward to reviewing v2!
Paolo
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Roman Kagan @ 2015-10-09 15:53 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Gleb Natapov, qemu-devel, virtualization, Christian Borntraeger,
Andrey Smetanin, Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <5617D259.8070101@redhat.com>
On Fri, Oct 09, 2015 at 04:42:33PM +0200, Paolo Bonzini wrote:
> You need to add SYNIC vectors to the EOI exit bitmap, so that APICv
> (Xeon E5 or higher, Ivy Bridge or newer) is handled correctly. You also
> need to check the auto EOI exit bitmap in __apic_accept_irq, and avoid
> going through kvm_x86_ops->deliver_posted_interrupt for auto EOI
> vectors. Something like
>
> if (kvm_x86_ops->deliver_posted_interrupt &&
> !test_bit(...))
>
> in place of the existing "if (kvm_x86_ops->deliver_posted_interrupt)".
Indeed, missed that path, thanks!
> I really don't like this auto-EOI extension, but I guess that's the
> spec. :( If it wasn't for it, you could do everything very easily in
> userspace using Google's proposed MSR exit.
I guess you're right. We'd probably have to (ab)use MSI for SINT
delivery, though. Anyway the need to implement auto-EOI rules that out.
Thanks for the quick review, we'll try to address your comments in the
next round.
Roman.
^ permalink raw reply
* Re: [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Paolo Bonzini @ 2015-10-09 14:57 UTC (permalink / raw)
To: Roman Kagan, Denis V. Lunev, virtualization, qemu-devel,
Andrey Smetanin, Vitaly Kuznetsov, K. Y. Srinivasan, Gleb Natapov
In-Reply-To: <20151009145358.GT27239@rkaganb.sw.ru>
On 09/10/2015 16:53, Roman Kagan wrote:
>> > Why is this exit necessary?
> The guest writes to synic-related MSRs and that should take "immediate"
> effect.
>
> E.g. it may decide to disable or relocate the message page by writing to
> SIMP MSR. The host is then supposed to stop accessing the old message
> page before the vCPU proceeds to the next instruction. Hence the exit,
> to allow the userspace to react accordingly before reentering the guest.
Ok, thanks!
Paolo
^ permalink raw reply
* Re: [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Roman Kagan @ 2015-10-09 14:53 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Gleb Natapov, qemu-devel, virtualization, Andrey Smetanin,
Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <5617D20B.1080402@redhat.com>
On Fri, Oct 09, 2015 at 04:41:15PM +0200, Paolo Bonzini wrote:
> On 09/10/2015 15:39, Denis V. Lunev wrote:
> > A new vcpu exit is introduced to notify the userspace of the
> > changes in Hyper-V synic configuraion triggered by guest writing to the
> > corresponding MSRs.
>
> Why is this exit necessary?
The guest writes to synic-related MSRs and that should take "immediate"
effect.
E.g. it may decide to disable or relocate the message page by writing to
SIMP MSR. The host is then supposed to stop accessing the old message
page before the vCPU proceeds to the next instruction. Hence the exit,
to allow the userspace to react accordingly before reentering the guest.
Roman.
^ permalink raw reply
* Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller
From: Paolo Bonzini @ 2015-10-09 14:42 UTC (permalink / raw)
To: Denis V. Lunev
Cc: Gleb Natapov, qemu-devel, virtualization, Christian Borntraeger,
rkagan, Andrey Smetanin, Vitaly Kuznetsov
In-Reply-To: <1444397988-20167-2-git-send-email-den@openvz.org>
Christian, the question for you is towards the end...
On 09/10/2015 15:39, Denis V. Lunev wrote:
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 62cf8c9..15c3c02 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -23,13 +23,265 @@
>
> #include "x86.h"
> #include "lapic.h"
> +#include "ioapic.h"
> #include "hyperv.h"
>
> #include <linux/kvm_host.h>
> +#include <asm/apicdef.h>
> #include <trace/events/kvm.h>
>
> #include "trace.h"
>
> +static inline u64 synic_read_sint(struct kvm_vcpu_hv_synic *synic, int sint)
> +{
> + return atomic64_read(&synic->sint[sint]);
> +}
> +
> +static inline int synic_get_sint_vector(u64 sint_value)
> +{
> + if (sint_value & HV_SYNIC_SINT_MASKED)
> + return -1;
> + return sint_value & HV_SYNIC_SINT_VECTOR_MASK;
> +}
> +
> +static bool synic_has_active_vector(struct kvm_vcpu_hv_synic *synic,
> + int vector, int sint_to_skip, int sint_mask)
> +{
> + u64 sint_value;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(synic->sint); i++) {
> + if (i == sint_to_skip)
> + continue;
> + sint_value = synic_read_sint(synic, i);
> + if ((synic_get_sint_vector(sint_value) == vector) &&
> + ((sint_mask == 0) || (sint_value & sint_mask)))
Coding style, no parentheses around && or ||:
if (synic_get_sint_vector(sint_value) == vector &&
(sint_mask == 0 || sint_value & sint_mask)
> + return true;
> + }
> + return false;
> +}
> +
> +static int synic_set_sint(struct kvm_vcpu_hv_synic *synic, int sint, u64 data)
> +{
> + int vector;
> +
> + vector = data & HV_SYNIC_SINT_VECTOR_MASK;
> + if (vector < 16)
> + return 1;
> + /*
> + * Guest may configure multiple SINTs to use the same vector, so
> + * we maintain a bitmap of vectors handled by synic, and a
> + * bitmap of vectors with auto-eoi behavoir. The bitmaps are
Typo (behavior).
> + * updated here, and atomically queried on fast paths.
> + */
> +
> + if (!(data & HV_SYNIC_SINT_MASKED)) {
> + __set_bit(vector, synic->vec_bitmap);
> + if (data & HV_SYNIC_SINT_AUTO_EOI)
> + __set_bit(vector, synic->auto_eoi_bitmap);
> + } else {
> + if (!synic_has_active_vector(synic, vector, sint, 0))
> + __clear_bit(vector, synic->vec_bitmap);
> + if (!synic_has_active_vector(synic, vector, sint,
> + HV_SYNIC_SINT_AUTO_EOI))
> + __clear_bit(vector, synic->auto_eoi_bitmap);
I think you could do the clears after the atomic64_set? Then you do not
need anymore the third argument to synic_has_active_vector. Actually I
think it's simpler if you just make two functions,
synic_is_vector_connected and synic_is_vector_auto_eoi. There is some
code duplication, but the functions are trivial.
> @@ -123,6 +125,15 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e,
> return kvm_irq_delivery_to_apic(kvm, NULL, &irq, NULL);
> }
>
> +int kvm_hv_set_sint(struct kvm_kernel_irq_routing_entry *e,
> + struct kvm *kvm, int irq_source_id, int level,
> + bool line_status)
> +{
> + if (!level)
> + return -1;
> +
> + return kvm_hv_synic_set_irq(kvm, e->hv_sint.vcpu, e->hv_sint.sint);
> +}
>
> static int kvm_set_msi_inatomic(struct kvm_kernel_irq_routing_entry *e,
> struct kvm *kvm)
> @@ -289,6 +300,11 @@ int kvm_set_routing_entry(struct kvm_kernel_irq_routing_entry *e,
> e->msi.address_hi = ue->u.msi.address_hi;
> e->msi.data = ue->u.msi.data;
> break;
> + case KVM_IRQ_ROUTING_HV_SINT:
> + e->set = kvm_hv_set_sint;
> + e->hv_sint.vcpu = ue->u.hv_sint.vcpu;
> + e->hv_sint.sint = ue->u.hv_sint.sint;
> + break;
> default:
> goto out;
> }
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 944b38a..63edbec 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -41,6 +41,7 @@
> #include "trace.h"
> #include "x86.h"
> #include "cpuid.h"
> +#include "hyperv.h"
>
> #ifndef CONFIG_X86_64
> #define mod_64(x, y) ((x) - (y) * div64_u64(x, y))
> @@ -128,11 +129,6 @@ static inline int apic_enabled(struct kvm_lapic *apic)
> (LVT_MASK | APIC_MODE_MASK | APIC_INPUT_POLARITY | \
> APIC_LVT_REMOTE_IRR | APIC_LVT_LEVEL_TRIGGER)
>
> -static inline int kvm_apic_id(struct kvm_lapic *apic)
> -{
> - return (kvm_apic_get_reg(apic, APIC_ID) >> 24) & 0xff;
> -}
> -
> /* The logical map is definitely wrong if we have multiple
> * modes at the same time. (Physical map is always right.)
> */
> @@ -972,6 +968,9 @@ static int apic_set_eoi(struct kvm_lapic *apic)
> apic_clear_isr(vector, apic);
> apic_update_ppr(apic);
>
> + if (test_bit(vector, vcpu_to_synic(apic->vcpu)->vec_bitmap))
> + kvm_hv_synic_send_eoi(apic->vcpu, vector);
> +
> kvm_ioapic_send_eoi(apic, vector);
> kvm_make_request(KVM_REQ_EVENT, apic->vcpu);
> return vector;
You need to add SYNIC vectors to the EOI exit bitmap, so that APICv
(Xeon E5 or higher, Ivy Bridge or newer) is handled correctly. You also
need to check the auto EOI exit bitmap in __apic_accept_irq, and avoid
going through kvm_x86_ops->deliver_posted_interrupt for auto EOI
vectors. Something like
if (kvm_x86_ops->deliver_posted_interrupt &&
!test_bit(...))
in place of the existing "if (kvm_x86_ops->deliver_posted_interrupt)".
I really don't like this auto-EOI extension, but I guess that's the
spec. :( If it wasn't for it, you could do everything very easily in
userspace using Google's proposed MSR exit.
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 3d70e36..3782636 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -63,9 +63,6 @@ enum hv_cpuid_function {
> /* Define version of the synthetic interrupt controller. */
> #define HV_SYNIC_VERSION (1)
>
> -/* Define the expected SynIC version. */
> -#define HV_SYNIC_VERSION_1 (0x1)
> -
> /* Define synthetic interrupt controller message constants. */
> #define HV_MESSAGE_SIZE (256)
> #define HV_MESSAGE_PAYLOAD_BYTE_COUNT (240)
> @@ -105,8 +102,6 @@ enum hv_message_type {
> HVMSG_X64_LEGACY_FP_ERROR = 0x80010005
> };
>
> -/* Define the number of synthetic interrupt sources. */
> -#define HV_SYNIC_SINT_COUNT (16)
> #define HV_SYNIC_STIMER_COUNT (4)
>
> /* Define invalid partition identifier. */
Please make these changes to drivers/hv and the uapi/ headers a separate
patch. I think the right header to move the constants to is not
include/uapi/linux/hyperv.h, but rather arch/x86/include/uapi/asm/hyperv.h.
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index b637965..0d7b705 100644
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
> @@ -192,11 +192,19 @@ irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
> irq = irqfd->irq_entry;
> } while (read_seqcount_retry(&irqfd->irq_entry_sc, seq));
> /* An event has been signaled, inject an interrupt */
> - if (irq.type == KVM_IRQ_ROUTING_MSI)
> + switch (irq.type) {
> + case KVM_IRQ_ROUTING_MSI:
> kvm_set_msi(&irq, kvm, KVM_USERSPACE_IRQ_SOURCE_ID, 1,
> false);
> - else
> + break;
> + case KVM_IRQ_ROUTING_HV_SINT:
> + kvm_hv_set_sint(&irq, kvm, KVM_USERSPACE_IRQ_SOURCE_ID,
> + 1, false);
> + break;
> + default:
> schedule_work(&irqfd->inject);
> + break;
> + }
Please make a new function kvm_arch_set_irq. The new function can
return true if the interrupt has been injected, and -EWOULDBLOCK if the
caller should call schedule_work(). The default implementation can be a
weak function in virt/kvm/eventfd.c.
> @@ -248,8 +256,9 @@ static void irqfd_update(struct kvm *kvm, struct kvm_kernel_irqfd *irqfd)
>
> e = entries;
> for (i = 0; i < n_entries; ++i, ++e) {
> - /* Only fast-path MSI. */
> - if (e->type == KVM_IRQ_ROUTING_MSI)
> + /* Fast-path MSI and Hyper-V sint */
> + if (e->type == KVM_IRQ_ROUTING_MSI ||
> + e->type == KVM_IRQ_ROUTING_HV_SINT)
> irqfd->irq_entry = *e;
> }
I think this "for" is unnecessary altogether. Instead, we should do:
if (n_entries == 1)
irqfd->irq_entry = *e;
else
irqfd->irq_entry.type = 0;
Because any other value for irq_entry.type will just trigger
schedule_work(&irqfd->inject). Please make it a separate patch, however.
> @@ -471,6 +480,24 @@ void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
> srcu_read_unlock(&kvm->irq_srcu, idx);
> }
>
> +void kvm_notify_acked_hv_sint(struct kvm_vcpu *vcpu, u32 sint)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_irq_ack_notifier *kian;
> + int gsi, idx;
> +
> + vcpu_debug(vcpu, "synic acked sint %d\n", sint);
> +
> + idx = srcu_read_lock(&kvm->irq_srcu);
> + gsi = kvm_hv_get_sint_gsi(vcpu, sint);
> + if (gsi != -1)
> + hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
> + link)
> + if (kian->gsi == gsi)
> + kian->irq_acked(kian);
> + srcu_read_unlock(&kvm->irq_srcu, idx);
> +}
Please move the hlist_for_each_entry_rcu to a new function
kvm_notify_acked_gsi. kvm_notify_acked_irq can use the new function as
well. Then this function can be moved to arch/x86/kvm/hyperv.c.
> +
> void kvm_register_irq_ack_notifier(struct kvm *kvm,
> struct kvm_irq_ack_notifier *kian)
> {
> diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
> index 716a1c4..1cf3d92 100644
> --- a/virt/kvm/irqchip.c
> +++ b/virt/kvm/irqchip.c
> @@ -144,11 +144,13 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt,
>
> /*
> * Do not allow GSI to be mapped to the same irqchip more than once.
> - * Allow only one to one mapping between GSI and MSI.
> + * Allow only one to one mapping between GSI and MSI/Hyper-V SINT.
> */
> hlist_for_each_entry(ei, &rt->map[ue->gsi], link)
> if (ei->type == KVM_IRQ_ROUTING_MSI ||
> ue->type == KVM_IRQ_ROUTING_MSI ||
> + ei->type == KVM_IRQ_ROUTING_HV_SINT ||
> + ue->type == KVM_IRQ_ROUTING_HV_SINT ||
> ue->u.irqchip.irqchip == ei->irqchip.irqchip)
> return r;
Christian, what's the desired behavior for s390 adapter interrupts here?
Should this actually become
if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
ue->u.irqchip.irqchip == ei->irqchip.irqchip)
? This would make sense, in that you shouldn't access "struct
kvm_irq_routing_irqchip" unless the type is set to
KVM_IRQ_ROUTING_IRQCHIP. Again, separate patch please.
> int kvm_set_irq_routing(struct kvm *kvm,
> const struct kvm_irq_routing_entry *ue,
> unsigned nr,
> @@ -219,6 +240,7 @@ int kvm_set_irq_routing(struct kvm *kvm,
> old = kvm->irq_routing;
> rcu_assign_pointer(kvm->irq_routing, new);
> kvm_irq_routing_update(kvm);
> + kvm_irq_update_hv_sint_gsi(kvm);
Please call this function kvm_arch_irq_routing_update, and (in a
separate patch) rename the existing kvm_arch_irq_routing_update to
kvm_arch_post_irq_routing_update.
Paolo
^ permalink raw reply
* Re: [PATCH 2/2] kvm/x86: Hyper-V kvm exit
From: Paolo Bonzini @ 2015-10-09 14:41 UTC (permalink / raw)
To: Denis V. Lunev
Cc: Gleb Natapov, qemu-devel, virtualization, rkagan, Andrey Smetanin,
Vitaly Kuznetsov
In-Reply-To: <1444397988-20167-3-git-send-email-den@openvz.org>
On 09/10/2015 15:39, Denis V. Lunev wrote:
> From: Andrey Smetanin <asmetanin@virtuozzo.com>
>
> A new vcpu exit is introduced to notify the userspace of the
> changes in Hyper-V synic configuraion triggered by guest writing to the
> corresponding MSRs.
>
> Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
> Reviewed-by: Roman Kagan <rkagan@virtiozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
> CC: "K. Y. Srinivasan" <kys@microsoft.com>
> CC: Gleb Natapov <gleb@kernel.org>
> CC: Paolo Bonzini <pbonzini@redhat.com>
Why is this exit necessary?
Paolo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox