[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
- To: Avi Kivity <avi@xxxxxxxxxx>
- From: Raghavendra K T <raghukt@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 02 Dec 2011 01:20:29 +0530
- Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, x86@xxxxxxxxxx, Gleb Natapov <gleb@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Xen <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dave Jiang <dave.jiang@xxxxxxxxx>, KVM <kvm@xxxxxxxxxxxxxxx>, Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Srivatsa Vaddagiri <vatsa@xxxxxxxxxxxxxxxxxx>, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Sasha Levin <levinsasha928@xxxxxxxxx>, Sedat Dilek <sedat.dilek@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Yinghai Lu <yinghai@xxxxxxxxxx>, Greg Kroah-Hartman <gregkh@xxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>, Suzuki Poulose <suzuki@xxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 02 Dec 2011 15:13:47 +0000
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
[ CCing Jeremy's new email ID ]
Hi Avi,
Thanks for review and inputs.
On 12/01/2011 04:41 PM, Avi Kivity wrote:
On 11/30/2011 10:59 AM, Raghavendra K T wrote:
The hypercall needs to be documented in
Documentation/virtual/kvm/hypercalls.txt.
Yes, Sure 'll document. hypercalls.txt is a new file right?. also I
have to document APIs in Documentation/virtual/kvm/api.txt.
Have you tested it on AMD machines? There are some differences in the
hypercall infrastructure there.
Yes. 'll test on AMD machine and update on that.
/* This indicates that the new set of kvmclock msrs
* are available. The use of 0x11 and 0x12 is deprecated
*/
#define KVM_FEATURE_CLOCKSOURCE2 3
#define KVM_FEATURE_ASYNC_PF 4
#define KVM_FEATURE_STEAL_TIME 5
+#define KVM_FEATURE_KICK_VCPU 6
Documentation/virtual/kvm/cpuid.txt.
Yes. 'll do that.
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..6e1c8b4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_XSAVE:
case KVM_CAP_ASYNC_PF:
case KVM_CAP_GET_TSC_KHZ:
+ case KVM_CAP_KICK_VCPU:
This is redundant with the feature bit? In general, KVM_CAP is for the
host API, while KVM_FEATURE is for the guest API.
No its not. I have to check the flow again. I understood that this
completes the guest querying, that checks for KVM_FEATURE availability.
Did I miss something? I need a little deep dive though.
+/*
+ * kvm_pv_kick_cpu_op: Kick a vcpu.
+ *
+ * @cpu - vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
+{
+ struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
There is no guarantee that guest cpu numbers match host vcpu numbers.
Use APIC IDs, and kvm_apic_match_dest().
Okay. I have to dig more on this.
+ struct kvm_mp_state mp_state;
+
+ mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
+ if (vcpu) {
+ vcpu->kicked = 1;
+ /* Ensure kicked is always set before wakeup */
+ barrier();
+ }
+ kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
This must only be called from the vcpu thread.
Hmm. Okay. 'll check this.
+ kvm_vcpu_kick(vcpu);
+}
+
struct kvm_vcpu_arch arch;
+
+ /*
+ * blocked vcpu wakes up by checking this flag set by unlocker.
+ */
+ int kicked;
Write only variable.
Yes 'll remove comments.
An alternative approach is to use an MSR protocol like x2apic ICR.
'll explore on this too.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
