From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3tuW-0007kH-V2 for qemu-devel@nongnu.org; Wed, 14 Sep 2011 14:10:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3tuV-00071R-Lb for qemu-devel@nongnu.org; Wed, 14 Sep 2011 14:10:12 -0400 Received: from goliath.siemens.de ([192.35.17.28]:32561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3tuV-00071L-8r for qemu-devel@nongnu.org; Wed, 14 Sep 2011 14:10:11 -0400 Message-ID: <4E70EDFF.4000008@siemens.com> Date: Wed, 14 Sep 2011 20:10:07 +0200 From: Jan Kiszka 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> In-Reply-To: <4E70EB39.4010101@siemens.com> Content-Type: text/plain; charset=UTF-8 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: Richard Henderson Cc: Blue Swirl , Avi Kivity , qemu-devel On 2011-09-14 19:58, Jan Kiszka wrote: > On 2011-09-14 17:10, Richard Henderson wrote: >> On 09/12/2011 02:19 AM, Jan Kiszka wrote: >>> On 2011-09-12 11:11, Avi Kivity wrote: >>>> On 09/12/2011 12:01 PM, Jan Kiszka wrote: >>>>> On 2011-09-12 08:43, Richard Henderson wrote: >>>>>> On 09/11/2011 09:31 PM, Blue Swirl wrote: >>>>>>> Field 'offset' is always zero, maybe that is not interesting. Will it >>>>>>> become one day? >>>>>> >>>>>> It's not always zero, but only used by certain devices. >>>>> >>>>> I do not see any users, neither upstream nor in Avi's tree. >>>> >>>> There aren't. >>>> >>>>> To my (semi-)understanding, offset should correlate to region_offset of >>>>> cpu_register_physical_memory_offset: legacy device models require this >>>>> to be 0 as they expect an absolute memory address passed to their >>>>> handler, in contrast to a normal one that is relative to the regions >>>>> base. But I do not see how the memory region offset actually helps here. >>>>> >>>> >>>> mr->offset is added to the address in memory_region_{read,write}_thunk_n(). >>> >>> Ah, ok. >>> >>> So the default address passed to the handler is now already relative? I >>> think we should keep it like this for all converted devices, ie. take >>> the chance, fix the remaining models, and drop the offset. >> >> It's non-zero for the isa portio conversion that I did, which >> I thought was in Avi's tree. > > Hmm, I wasn't looking at PIO yet as it was out of scope of the original > MMIO offset. But good to known. OK, let's try again: Do we have to model hierarchy in PIO address space at all? I don't think so. Rather, devices dispatch the full address range, thus are aware of the absolute addresses they listen to. So we are supposed to pass absolute addresses down to the handlers anyway, and offset is useless for PIO as well. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux