From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWAMv-0000Zh-J8 for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:24:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWAMs-0007A4-GI for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:24:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWAMs-00079q-9m for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:24:18 -0500 Message-ID: <4ED7B83E.3080300@redhat.com> Date: Thu, 01 Dec 2011 19:24:14 +0200 From: Avi Kivity 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> <4ED7B6DC.8000300@suse.de> In-Reply-To: <4ED7B6DC.8000300@suse.de> 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: qemu-devel@nongnu.org, Gleb Natapov On 12/01/2011 07:18 PM, Andreas F=E4rber wrote: > 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 norm= al > >>>>>> 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 le= t 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 mem= ory > >>> access below TOM will be redirected to memory controller no matter = what) > > Ah, glad to know that x86_64 is no longer affected. What about 0.15.1? In 0.15 this can still happen, 1.0 was fixed by the memory API. Note the fix is actually a side effect of a different change, and the issue can still happen for other reasons (as in your case). --=20 error compiling committee.c: too many arguments to function