From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roedel, Joerg" Subject: Re: kvm_amd BUG: unable to handle kernel NULL pointer dereference at 00000014 Date: Mon, 7 Mar 2011 14:16:49 +0100 Message-ID: <20110307131649.GF17719@amd.com> References: <4D736090.1000300@redhat.com> <20110307121138.GD17719@amd.com> <4D74D486.2080206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: IVAN ANGELOV , "kvm@vger.kernel.org" , Ingo Molnar , "x86@kernel.org" To: Avi Kivity Return-path: Received: from db3ehsobe004.messaging.microsoft.com ([213.199.154.142]:11976 "EHLO DB3EHSOBE004.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752367Ab1CGNRh (ORCPT ); Mon, 7 Mar 2011 08:17:37 -0500 Content-Disposition: inline In-Reply-To: <4D74D486.2080206@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Mar 07, 2011 at 07:50:14AM -0500, Avi Kivity wrote: > On 03/07/2011 02:11 PM, Roedel, Joerg wrote: > > There is no access to per_cpu variables at the start of x86_decode_insn. > > I did a bit of investigation and it turns out that the faulting > > instruction is inserted into the code by the gcc because the > > CONFIG_CC_STACKPROTECTOR is enabled. > > The user tested this is Ubuntu 11.04 alpha-something i386 and this > > distro uses gcc 4.5.2. So CC_STACKPROTECTOR seems to be harmful with > > this gcc version but I am not sure whether this counts as a gcc bug. > > Ah, looks like %gs is the expected segment on i386 with > -fstack-protector. So we must disable lazy gs reload in that scenario. According to the comments in stackprotector.h its the same on amd64 (the difference is that gcc expects the canary value at a different offset from %gs). So we should probably unlazy %gs reload alltogether. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632