From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVjyH-000681-2y for qemu-devel@nongnu.org; Sun, 12 Jun 2011 08:40:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVjyF-000142-7u for qemu-devel@nongnu.org; Sun, 12 Jun 2011 08:40:52 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:47797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVjyE-00013D-Cw for qemu-devel@nongnu.org; Sun, 12 Jun 2011 08:40:51 -0400 Message-ID: <4DF4B3C3.7000907@reactos.org> Date: Sun, 12 Jun 2011 14:40:35 +0200 From: =?ISO-8859-1?Q?Herv=E9_Poussineau?= MIME-Version: 1.0 References: <1292973623-2455-1-git-send-email-andreas.faerber@web.de> <20101222025014.GA20337@valinux.co.jp> <4D119B09.30103@reactos.org> <20101222064921.GE7814@redhat.com> <193FFA10-B7C4-4928-ADDE-C874C56BE70C@web.de> In-Reply-To: <193FFA10-B7C4-4928-ADDE-C874C56BE70C@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Isaku Yamahata , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , qemu-devel Developers , "Michael S. Tsirkin" Andreas, Andreas F=E4rber a =E9crit : > > Herv=E9, > > Am 22.12.2010 um 07:49 schrieb Michael S. Tsirkin: > >> On Wed, Dec 22, 2010 at 07:30:33AM +0100, Herv=E9 Poussineau wrote: >>> Isaku Yamahata a =E9crit : >>>> On Wed, Dec 22, 2010 at 12:20:23AM +0100, Andreas F=E4rber wrote: >>>>> From: Herv=E9 Poussineau >>>>> >>>>> v1: >>>>> * Rebased. >>>>> >>>>> Signed-off-by: Herv=E9 Poussineau >>>>> Cc: Michael S. Tsirkin >>>>> Signed-off-by: Andreas F=E4rber >>>>> --- >>>>> Hello Michael, >>>>> Could you please take a look at this? I'm out of my field here. >>>>> The intention of the first part appears to be to save (val & ~mask)= , >>>>> whereas the inline helper would've returned (val & mask). >>>> >>>> Such behavior is intended. >>>> The returned value is just discarded in this case. >>>> test-and-clear means >>>> clear the bits >>>> return if those cleared bits were really set. >>>> >> >> What about this first chunk? Is it necessary. >> >>>>> The second part makes existing code conditional on that value. >>>> >>>> What issue are you addressing? >>>> Although the spec doesn't says about the default value of BAR=20 >>>> registers >>>> after reset, the current code assumes that almost all the pci=20 >>>> devices clear >>>> those registers. >>>> Anyway after cold/warm reset firmware sets up BARs, so it doesn't=20 >>>> matter. >>>> You, however, seem to want to keep BARs over resets. >>>> >>>> thanks, >>>> >>>> >>> As you have seen, the intend here is to be able to keep BARs over=20 >>> resets. >>> It is required for some really specific devices, like a PCI to ISA >>> bridge, where MMIO is always at the same address. >>> In that case, the device keeps PCI_COMMAND_MEMORY and/or >>> PCI_COMMAND_IO flags as read-only. >>> >>> Herv=E9 >> >> Aha. Are the BARs still writeable? If not maybe that's the right thin= g >> to check? If yes maybe the device simply should have a reset >> handler to rewrite them? > > I haven't noticed a follow-up patch of yours. > > Since I don't know what to do here, I'll have to take this out of the=20 > PReP queue for now. > Without this patch, I get to at least the second bootloader icon, the=20 > PCI graphics still work. What particular symptoms did you observe wrt=20 > the i82378 that we can reproduce? > > Thanks, > Andreas > Try do do info qtree with and without this patch, and check the i82378=20 device With this patch, I have: bar 0: mem at 0x80000000 [0x8000ffff] bar 1: mem at 0xc0000000 [0xc0ffffff] Without it, I have: bar 0: mem at 0xffffffffffffffff [0xfffe] bar 1: mem at 0xffffffffffffffff [0xfffffe] I think that firmware doesn't initialize BARs for this device. However,=20 I don't know what can be the consequences of not doing it. Regards, Herv=E9