From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R48dS-0004J9-Iz for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:53:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R48dR-0003w3-L9 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:53:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R48dR-0003vp-Cg for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:53:33 -0400 Message-ID: <4E71CB19.2010605@redhat.com> Date: Thu, 15 Sep 2011 12:53:29 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E6DAA09.1050701@twiddle.net> <4E6DCA61.4070009@siemens.com> <4E6DCCC4.1050201@redhat.com> <4E6DCE8D.9040602@siemens.com> <4E70C402.3090907@twiddle.net> <4E70EB39.4010101@siemens.com> <4E70EDFF.4000008@siemens.com> <4E70FF6A.8050401@redhat.com> <4E71C5BF.7050409@siemens.com> In-Reply-To: <4E71C5BF.7050409@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] memory: simple memory tree printer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , qemu-devel , Richard Henderson On 09/15/2011 12:30 PM, Jan Kiszka wrote: > On 2011-09-14 21:24, Avi Kivity wrote: > > On 09/14/2011 09:10 PM, Jan Kiszka wrote: > >> OK, let's try again: Do we have to model hierarchy in PIO address space > >> at all? I don't think so. > > > > > > We do. A device listens to addresses 0x100-0x110. Another BAR (at > > 0x106) clips this to 0x100-0x106. The pci/pci bridge clips this to > > 0x105-0x106. > > OK, but clipping does not require offsets as it does not register PIO > regions at different base addresses. It's a pure internal representation > when flatting the view. A hierarchy is needed. > > > The host pci bridge remaps this as > > 0x1000000105-0x1000000106 in the memory address space space. But > > someone configured a cpu-local region at this address, so the cpu can't > > reach it at all. > > Mapping PIO into MMIO space is special as it needs an intermediate layer > (ie. translation handlers). Translation handlers aren't needed - you can simply add the pci pio region as a subregion of the mmio space. > Anyway, the point is that there are device models out there > (specifically PCI devices) that already use relative PIO addresses and > models (specifically ISA) that still expect absolute addresses (/wrt to > the ISA base). I believe it is better to consolidate over one model > longterm, but we need a transition phase here as well. However, I'm > unsure yet if we really need MemoryRegion::offset for that and cannot > use MemoryRegionPortio::offset. Need to look into the details. It would be good to get rid of MemoryRegion::offset. -- error compiling committee.c: too many arguments to function