From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3r7H-0000Z7-NR for qemu-devel@nongnu.org; Wed, 14 Sep 2011 11:11:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3r7D-00027m-5K for qemu-devel@nongnu.org; Wed, 14 Sep 2011 11:11:11 -0400 Received: from mail-gx0-f181.google.com ([209.85.161.181]:37025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3r7D-00027Q-1g for qemu-devel@nongnu.org; Wed, 14 Sep 2011 11:11:07 -0400 Received: by gxk9 with SMTP id 9so2167761gxk.12 for ; Wed, 14 Sep 2011 08:11:06 -0700 (PDT) Sender: Richard Henderson Message-ID: <4E70C402.3090907@twiddle.net> Date: Wed, 14 Sep 2011 08:10:58 -0700 From: Richard Henderson MIME-Version: 1.0 References: <4E6DAA09.1050701@twiddle.net> <4E6DCA61.4070009@siemens.com> <4E6DCCC4.1050201@redhat.com> <4E6DCE8D.9040602@siemens.com> In-Reply-To: <4E6DCE8D.9040602@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: Jan Kiszka Cc: Blue Swirl , Avi Kivity , qemu-devel 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. This is required by at least the VGA and GUS ISA devices which do expect absolute i/o addresses, and check them. The offset is used to convert the relative i/o address back into an absolute address. It would also be used when we split an ISA portio region, as with the FDC device. There, we have 7 ports in 2 chunks. The offset would still be needed to convert the relative offset of the second chuck to be relative to the "real" un-split region. Feel free to convert all of these devices to a more "native" use of the memory api, but I warn you it won't be trivial. r~