From: David Woodhouse <dwmw2@infradead.org>
To: kvm@vger.kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Ankur Arora <ankur.a.arora@oracle.com>,
Joao Martins <joao.m.martins@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Sean Christopherson <seanjc@google.com>,
graf@amazon.com, iaslan@amazon.de, pdurrant@amazon.com,
aagch@amazon.com, fandree@amazon.com, hch@infradead.org
Subject: [PATCH v5 16/16] KVM: x86/xen: Add event channel interrupt vector upcall
Date: Mon, 11 Jan 2021 19:57:25 +0000 [thread overview]
Message-ID: <20210111195725.4601-17-dwmw2@infradead.org> (raw)
In-Reply-To: <20210111195725.4601-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
It turns out that we can't handle event channels *entirely* in userspace
by delivering them as ExtINT, because KVM is a bit picky about when it
accepts ExtINT interrupts from a legacy PIC. The in-kernel local APIC
has to have LVT0 configured in APIC_MODE_EXTINT and unmasked, which
isn't necessarily the case for Xen guests especially on secondary CPUs.
To cope with this, add kvm_xen_get_interrupt() which checks the
evtchn_pending_upcall field in the Xen vcpu_info, and delivers the Xen
upcall vector (configured by KVM_XEN_ATTR_TYPE_UPCALL_VECTOR) if it's
set regardless of LAPIC LVT0 configuration. This gives us the minimum
support we need for completely userspace-based implementation of event
channels.
This does mean that vcpu_enter_guest() needs to check for the
evtchn_pending_upcall flag being set, because it can't rely on someone
having set KVM_REQ_EVENT unless we were to add some way for userspace to
do so manually.
But actually, I don't quite see how that works reliably for interrupts
injected with KVM_INTERRUPT either. In kvm_vcpu_ioctl_interrupt() the
KVM_REQ_EVENT request is set once, but that'll get cleared the first time
through vcpu_enter_guest(). So if the first exit is for something *else*
without interrupts being enabled yet, won't the KVM_REQ_EVENT request
have been consumed already and just be lost?
I wonder if my addition of '|| kvm_xen_has_interrupt(vcpu)' should
actually be '|| kvm_has_injectable_intr(vcpu)' to fix that pre-existing
bug?
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/irq.c | 7 +++++
arch/x86/kvm/x86.c | 3 +-
arch/x86/kvm/xen.c | 52 +++++++++++++++++++++++++++++++++
arch/x86/kvm/xen.h | 1 +
include/uapi/linux/kvm.h | 2 ++
6 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 73f285ebb181..b1cc73a19021 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -907,6 +907,7 @@ struct msr_bitmap_range {
struct kvm_xen {
bool long_mode;
bool shinfo_set;
+ u8 upcall_vector;
struct gfn_to_hva_cache shinfo_cache;
};
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 814698e5b152..24668b51b5c8 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -14,6 +14,7 @@
#include "irq.h"
#include "i8254.h"
#include "x86.h"
+#include "xen.h"
/*
* check if there are pending timer events
@@ -56,6 +57,9 @@ int kvm_cpu_has_extint(struct kvm_vcpu *v)
if (!lapic_in_kernel(v))
return v->arch.interrupt.injected;
+ if (kvm_xen_has_interrupt(v))
+ return 1;
+
if (!kvm_apic_accept_pic_intr(v))
return 0;
@@ -110,6 +114,9 @@ static int kvm_cpu_get_extint(struct kvm_vcpu *v)
if (!lapic_in_kernel(v))
return v->arch.interrupt.nr;
+ if (kvm_xen_has_interrupt(v))
+ return v->kvm->arch.xen.upcall_vector;
+
if (irqchip_split(v->kvm)) {
int vector = v->arch.pending_external_vector;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 25ef3b7ad49d..aa3c38fa3f31 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8950,7 +8950,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
kvm_x86_ops.msr_filter_changed(vcpu);
}
- if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
+ if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win ||
+ kvm_xen_has_interrupt(vcpu)) {
++vcpu->stat.req_event;
kvm_apic_accept_events(vcpu);
if (vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED) {
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 17cbb4462b7e..4bc9da9fcfb8 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -176,6 +176,45 @@ void kvm_xen_setup_runstate_page(struct kvm_vcpu *v)
kvm_xen_update_runstate(v, RUNSTATE_running, steal_time);
}
+int kvm_xen_has_interrupt(struct kvm_vcpu *v)
+{
+ u8 rc = 0;
+
+ /*
+ * If the global upcall vector (HVMIRQ_callback_vector) is set and
+ * the vCPU's evtchn_upcall_pending flag is set, the IRQ is pending.
+ */
+ if (v->arch.xen.vcpu_info_set && v->kvm->arch.xen.upcall_vector) {
+ struct gfn_to_hva_cache *ghc = &v->arch.xen.vcpu_info_cache;
+ struct kvm_memslots *slots = kvm_memslots(v->kvm);
+ unsigned int offset = offsetof(struct vcpu_info, evtchn_upcall_pending);
+
+ /* No need for compat handling here */
+ BUILD_BUG_ON(offsetof(struct vcpu_info, evtchn_upcall_pending) !=
+ offsetof(struct compat_vcpu_info, evtchn_upcall_pending));
+ BUILD_BUG_ON(sizeof(rc) !=
+ sizeof(((struct vcpu_info *)0)->evtchn_upcall_pending));
+ BUILD_BUG_ON(sizeof(rc) !=
+ sizeof(((struct compat_vcpu_info *)0)->evtchn_upcall_pending));
+
+ /*
+ * For efficiency, this mirrors the checks for using the valid
+ * cache in kvm_read_guest_offset_cached(), but just uses
+ * __get_user() instead. And falls back to the slow path.
+ */
+ if (likely(slots->generation == ghc->generation &&
+ !kvm_is_error_hva(ghc->hva) && ghc->memslot)) {
+ /* Fast path */
+ __get_user(rc, (u8 __user *)ghc->hva + offset);
+ } else {
+ /* Slow path */
+ kvm_read_guest_offset_cached(v->kvm, ghc, &rc, offset,
+ sizeof(rc));
+ }
+ }
+ return rc;
+}
+
int kvm_xen_hvm_set_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data)
{
struct kvm_vcpu *v;
@@ -245,6 +284,14 @@ int kvm_xen_hvm_set_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data)
v->arch.xen.last_state_ns = ktime_get_ns();
break;
+ case KVM_XEN_ATTR_TYPE_UPCALL_VECTOR:
+ if (data->u.vector < 0x10)
+ return -EINVAL;
+
+ kvm->arch.xen.upcall_vector = data->u.vector;
+ r = 0;
+ break;
+
default:
break;
}
@@ -303,6 +350,11 @@ int kvm_xen_hvm_get_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data)
}
break;
+ case KVM_XEN_ATTR_TYPE_UPCALL_VECTOR:
+ data->u.vector = kvm->arch.xen.upcall_vector;
+ r = 0;
+ break;
+
default:
break;
}
diff --git a/arch/x86/kvm/xen.h b/arch/x86/kvm/xen.h
index 407e717476d6..d64916ac4a12 100644
--- a/arch/x86/kvm/xen.h
+++ b/arch/x86/kvm/xen.h
@@ -11,6 +11,7 @@
void kvm_xen_setup_runstate_page(struct kvm_vcpu *vcpu);
void kvm_xen_runstate_set_preempted(struct kvm_vcpu *vcpu);
+int kvm_xen_has_interrupt(struct kvm_vcpu *vcpu);
int kvm_xen_hvm_set_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data);
int kvm_xen_hvm_get_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data);
int kvm_xen_hypercall(struct kvm_vcpu *vcpu);
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index e468f923e7dd..f814cccc0d00 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1595,6 +1595,7 @@ struct kvm_xen_hvm_attr {
__u16 pad[3];
union {
__u8 long_mode;
+ __u8 vector;
struct {
__u64 gfn;
} shared_info;
@@ -1612,6 +1613,7 @@ struct kvm_xen_hvm_attr {
#define KVM_XEN_ATTR_TYPE_VCPU_INFO 0x2
#define KVM_XEN_ATTR_TYPE_VCPU_TIME_INFO 0x3
#define KVM_XEN_ATTR_TYPE_VCPU_RUNSTATE 0x4
+#define KVM_XEN_ATTR_TYPE_UPCALL_VECTOR 0x5
/* Secure Encrypted Virtualization command */
enum sev_cmd_id {
--
2.29.2
next prev parent reply other threads:[~2021-01-11 19:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 19:57 [PATCH v5 00/16] KVM: Add minimal support for Xen HVM guests David Woodhouse
2021-01-11 19:57 ` [PATCH v5 01/16] KVM: x86/xen: fix Xen hypercall page msr handling David Woodhouse
2021-01-11 19:57 ` [PATCH v5 02/16] KVM: x86/xen: intercept xen hypercalls if enabled David Woodhouse
2021-01-11 23:42 ` kernel test robot
2021-01-28 12:21 ` Paolo Bonzini
2021-01-11 19:57 ` [PATCH v5 03/16] KVM: x86/xen: Fix coexistence of Xen and Hyper-V hypercalls David Woodhouse
2021-01-11 19:57 ` [PATCH v5 04/16] KVM: x86/xen: add KVM_XEN_HVM_SET_ATTR/KVM_XEN_HVM_GET_ATTR David Woodhouse
2021-01-11 19:57 ` [PATCH v5 05/16] KVM: x86/xen: latch long_mode when hypercall page is set up David Woodhouse
2021-01-11 19:57 ` [PATCH v5 06/16] KVM: x86/xen: add definitions of compat_shared_info, compat_vcpu_info David Woodhouse
2021-01-11 19:57 ` [PATCH v5 07/16] KVM: x86/xen: register shared_info page David Woodhouse
2021-01-11 19:57 ` [PATCH v5 08/16] xen: add wc_sec_hi to struct shared_info David Woodhouse
2021-01-11 19:57 ` [PATCH v5 09/16] KVM: x86/xen: update wallclock region David Woodhouse
2021-01-11 19:57 ` [PATCH v5 10/16] KVM: x86/xen: register vcpu info David Woodhouse
2021-01-11 19:57 ` [PATCH v5 11/16] KVM: x86/xen: setup pvclock updates David Woodhouse
2021-01-11 19:57 ` [PATCH v5 12/16] KVM: x86/xen: register vcpu time info region David Woodhouse
2021-01-11 19:57 ` [PATCH v5 13/16] KVM: x86/xen: register runstate info David Woodhouse
2021-01-28 12:15 ` Paolo Bonzini
2021-01-11 19:57 ` [PATCH v5 14/16] KVM: x86: declare Xen HVM shared info capability and add test case David Woodhouse
2021-01-11 19:57 ` [PATCH v5 15/16] KVM: Add documentation for Xen hypercall and shared_info updates David Woodhouse
2021-01-28 12:18 ` Paolo Bonzini
2021-01-28 16:49 ` David Woodhouse
2021-01-28 17:06 ` Paolo Bonzini
[not found] ` <f9b2b4e613ea4e6dd1f253f5092254d121c93c07.camel@infradead.org>
2021-01-29 7:59 ` Paolo Bonzini
2021-01-11 19:57 ` David Woodhouse [this message]
2021-01-28 12:43 ` [PATCH v5 16/16] KVM: x86/xen: Add event channel interrupt vector upcall Paolo Bonzini
2021-01-28 15:35 ` David Woodhouse
2021-01-28 17:01 ` Paolo Bonzini
2021-01-29 17:33 ` David Woodhouse
2021-01-29 19:19 ` Paolo Bonzini
2021-01-30 13:01 ` David Woodhouse
2021-01-21 11:56 ` [PATCH v5 17/16] KVM: x86/xen: Fix initialisation of gfn caches for Xen shared pages David Woodhouse
2021-01-28 12:45 ` [PATCH v5 00/16] KVM: Add minimal support for Xen HVM guests Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210111195725.4601-17-dwmw2@infradead.org \
--to=dwmw2@infradead.org \
--cc=aagch@amazon.com \
--cc=ankur.a.arora@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=fandree@amazon.com \
--cc=graf@amazon.com \
--cc=hch@infradead.org \
--cc=iaslan@amazon.de \
--cc=joao.m.martins@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).