[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [BUG] Guest kernel divide error in kvm_unlock_kick
From: |
Chris Webb |
Subject: |
Re: [Qemu-devel] [BUG] Guest kernel divide error in kvm_unlock_kick |
Date: |
Mon, 22 Sep 2014 20:08:43 +0100 |
Paolo Bonzini <address@hidden> wrote:
> Il 11/09/2014 19:03, Chris Webb ha scritto:
>> Paolo Bonzini <address@hidden> 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.