On 10/04/2010 05:56 PM, Gleb Natapov wrote:
Enable async PF in a guest if async PF capability is discovered.
+void __cpuinit kvm_guest_cpu_init(void)
+{
+ if (!kvm_para_available())
+ return;
+
+ if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF)&& kvmapf) {
+ u64 pa = __pa(&__get_cpu_var(apf_reason));
+
+ if (native_write_msr_safe(MSR_KVM_ASYNC_PF_EN,
+ pa | KVM_ASYNC_PF_ENABLED, pa>> 32))
native_ versions of processor accessors shouldn't be used generally.
Also, the MSR isn't documented to fail on valid input, so you can use a
normal wrmsrl() here.
+ return;
+ __get_cpu_var(apf_reason).enabled = 1;
+ printk(KERN_INFO"KVM setup async PF for cpu %d\n",
+ smp_processor_id());
+ }
+}
+
+static int kvm_pv_reboot_notify(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+ if (code == SYS_RESTART)
+ on_each_cpu(kvm_pv_disable_apf, NULL, 1);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block kvm_pv_reboot_nb = {
+ .notifier_call = kvm_pv_reboot_notify,
+};
Does this handle kexec?
+
+static void kvm_guest_cpu_notify(void *dummy)
+{
+ if (!dummy)
+ kvm_guest_cpu_init();
+ else
+ kvm_pv_disable_apf(NULL);
+}
Why are you making decisions based on a dummy input?
The whole thing looks strange. Use two functions?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
