From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [BUG] Guest kernel divide error in kvm_unlock_kick Date: Mon, 22 Sep 2014 21:14:34 +0200 Message-ID: <5420751A.60602@redhat.com> References: <54116F40.8090704@redhat.com> <13C45040-67E9-4634-BD9E-4A89B0BD95C0@arachsys.com> <542000CB.4070103@redhat.com> <435C1323-1441-47A2-86E6-404BAD9356FC@arachsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Chris Webb Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37868 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751791AbaIVTOp (ORCPT ); Mon, 22 Sep 2014 15:14:45 -0400 In-Reply-To: <435C1323-1441-47A2-86E6-404BAD9356FC@arachsys.com> Sender: kvm-owner@vger.kernel.org List-ID: Il 22/09/2014 21:08, Chris Webb ha scritto: > > 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? I posted a patch to use alternatives if CONFIG_DEBUG_RODATA is enabled, but the bug is in KVM that explicitly documents "you can use any of VMCALL or VMMCALL". I'll also see to fix KVM, but the patch is still useful because a) KVM would not patch a read-only text segment, so there would be a small performance benefit; b) you cannot control already deployed hypervisors. However, since there is a workaround, I won't push it into 3.17 so late in the cycle. Also, there's a chance that it is NACKed since it touches non-KVM files. Paolo