From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jf1hS-0006Sj-R9 for qemu-devel@nongnu.org; Thu, 27 Mar 2008 19:40:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jf1hS-0006SV-2Q for qemu-devel@nongnu.org; Thu, 27 Mar 2008 19:40:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jf1hR-0006SS-TW for qemu-devel@nongnu.org; Thu, 27 Mar 2008 19:40:01 -0400 Received: from hall.aurel32.net ([88.191.38.19]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jf1hR-0003QD-H8 for qemu-devel@nongnu.org; Thu, 27 Mar 2008 19:40:01 -0400 Date: Fri, 28 Mar 2008 00:39:51 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH] ignore reads to the EOI register. Message-ID: <20080327233951.GA5803@volta.aurel32.net> References: <12065794361493-git-send-email-gcosta@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <12065794361493-git-send-email-gcosta@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm-devel@lists.sourceforge.net, glommer@gmail.com, macro@linux-mips.org, Glauber Costa On Wed, Mar 26, 2008 at 09:57:16PM -0300, Glauber Costa wrote: > They seem legal in real hardware, even though the EOI > is a write-only register. By "legal" I mean they are completely > ignored, but at least, don't cause any bits to be set at ESR. > > Without this patch, some (very recent) linux git trees will fail > to boot in i386. > > This is generated from kvm-userspace, but should apply well to > plain qemu too. > > Signed-off-by: Glauber Costa > --- > qemu/hw/apic.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c > index 92248dd..4102493 100644 > --- a/qemu/hw/apic.c > +++ b/qemu/hw/apic.c > @@ -615,6 +615,8 @@ static uint32_t apic_mem_readl(void *opaque, target_phys_addr_t addr) > /* ppr */ > val = apic_get_ppr(s); > break; > + case 0x0b: > + break; While I agree the guest should not care of the value (it should actually not read it), wouldn't it be safer to return a default value (0 ?) instead of an initialized value? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net