From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWAHz-0005Wu-RR for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:19:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWAHx-0005IF-Gm for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:19:15 -0500 Received: from cantor2.suse.de ([195.135.220.15]:52950 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWAHx-0005HF-8g for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:19:13 -0500 Message-ID: <4ED7B6DC.8000300@suse.de> Date: Thu, 01 Dec 2011 18:18:20 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1322666781-6108-1-git-send-email-afaerber@suse.de> <4ED7490C.7050505@redhat.com> <20111201093706.GA13420@redhat.com> <4ED74BE0.2020406@redhat.com> <20111201094710.GB13420@redhat.com> <4ED74ED9.90603@redhat.com> <20111201100630.GC13420@redhat.com> In-Reply-To: <20111201100630.GC13420@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] exec.c: Fix subpage memory access to RAM MemoryRegion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Avi Kivity , qemu-devel@nongnu.org Am 01.12.2011 11:06, schrieb Gleb Natapov: > On Thu, Dec 01, 2011 at 11:54:33AM +0200, Avi Kivity wrote: >> On 12/01/2011 11:47 AM, Gleb Natapov wrote: >>> On Thu, Dec 01, 2011 at 11:41:52AM +0200, Avi Kivity wrote: >>>> On 12/01/2011 11:37 AM, Gleb Natapov wrote: >>>>>> >>>>>> Looks reasonable. Should go into 1.1. Should we backport it to >>>>>> 1.0.blah? From 95c318f's description, it doesn't happen in normal >>>>>> circumstances. >>>>>> >>>>> To reproduce that I mappped subpage PCI bar over RAM IIRC.=20 >>>> >>>> In qemu 1.0, you can no longer do that (the pci bridge will not let = the >>>> BAR override the RAM). >>>> >>> >>> Hmm, if this is how real HW work then problem solved :) (different HW= can >>> behave differently, but it is reasonable to assume that on a PC memor= y >>> access below TOM will be redirected to memory controller no matter wh= at) Ah, glad to know that x86_64 is no longer affected. What about 0.15.1? >>> So what is the motivation for Andreas patch than? >>> >> >> He's not emulating pc hardware. >> > That's not a crime in itself :) What HW he encountered this problem on? > What scenario? How likely is this scenario on that HW (my comment for > 95c318f which you are referring to above was for PC)? I encountered this on a nommu architecture that's not yet upstream (78k0 family / rl78). The exact scenario was a 256-byte long RAM area for Special Function Registers (fixable by 8-bit pages) and a 32-byte long RAM subarea for memory-mapped banked GPRs (not fixable by lowering page size to 5, doesn't build). I'm aware that the former I could convert to mmio and the latter I might drop but that's besides the point, it's not prohibited by MemoryRegion API and silently fails unless DEBUG_UNASSIGNED enabled. Seems worth a fix= . Upstream potential no-mmu architectures and their target page sizes are: lm32 (12) m68k (10) microblaze (12) mips (12) xtensa (12) > And if KVM is > supported on that HW my comment about KVM still applies. I don't think KVM is supported on any of the above. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg