From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW94V-0005Va-RG for qemu-devel@nongnu.org; Mon, 22 Sep 2014 15:14:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW94P-0004fS-N6 for qemu-devel@nongnu.org; Mon, 22 Sep 2014 15:14:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW94P-0004f3-Fk for qemu-devel@nongnu.org; Mon, 22 Sep 2014 15:14:45 -0400 Message-ID: <5420751A.60602@redhat.com> Date: Mon, 22 Sep 2014 21:14:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <54116F40.8090704@redhat.com> <13C45040-67E9-4634-BD9E-4A89B0BD95C0@arachsys.com> <542000CB.4070103@redhat.com> <435C1323-1441-47A2-86E6-404BAD9356FC@arachsys.com> In-Reply-To: <435C1323-1441-47A2-86E6-404BAD9356FC@arachsys.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [BUG] Guest kernel divide error in kvm_unlock_kick List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Webb Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org 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