Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 11/09/2014 19:03, Chris Webb ha scritto: >> Paolo Bonzini <pbonz...@redhat.com> wrote: >> >>> This is a hypercall that should have kicked VCPU 3 (see rcx). >>> >>> Can you please apply this patch and gather a trace of the host >>> (using "trace-cmd -e kvm qemu-kvm <arguments>")? >> >> Sure, no problem. I've built the trace-cmd tool against udis86 (I hope) and >> have put the resulting trace.dat at >> >> http://cdw.me.uk/tmp/trace.dat >> >> This is actually for a -smp 2 qemu (failing to kick VCPU 1?) as I was having >> trouble persuading the -smp 4 qemu to crash as reliably under tracing. >> (Something timing related?) Otherwise the qemu-system-x86 command line is >> exactly as before. > > Do you by chance have CONFIG_DEBUG_RODATA set? In that case, the fix is > simply not to set it.
Absolutely right: my host and guest kernels do have CONFIG_DEBUG_RODATA set! Your patch to use alternatives for VMCALL vs VMMCALL definitely fixed the divide-by-zero crashes I saw. Given that I can easily use either (or both) of these solutions, is it be more efficient to turn off CONFIG_DEBUG_RODATA in the guest kernel so kvm can fix up the instructions in-place, or is using alternatives for VMCALL/VMMCALL as implemented by your patch just as good? Best wishes, Chris.-- 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
