From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuXBT-0000kX-Qz for qemu-devel@nongnu.org; Wed, 24 Mar 2010 16:28:11 -0400 Received: from [140.186.70.92] (port=43028 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuXBR-0000iZ-CT for qemu-devel@nongnu.org; Wed, 24 Mar 2010 16:28:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuXBO-0006mx-7X for qemu-devel@nongnu.org; Wed, 24 Mar 2010 16:28:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31662) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuXBN-0006mr-U9 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 16:28:06 -0400 Date: Wed, 24 Mar 2010 22:24:29 +0200 From: "Michael S. Tsirkin" Message-ID: <20100324202429.GA11172@redhat.com> References: <20100324193903.GA11004@redhat.com> <20100324200848.GA11133@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: Compile files only once: some planning List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On Wed, Mar 24, 2010 at 10:24:12PM +0200, Blue Swirl wrote: > On 3/24/10, Michael S. Tsirkin wrote: > > On Wed, Mar 24, 2010 at 10:05:10PM +0200, Blue Swirl wrote: > > > On 3/24/10, Michael S. Tsirkin wrote: > > > > On Tue, Mar 23, 2010 at 11:43:51PM +0200, Blue Swirl wrote: > > > > > rtl8139.c, e1000.c: need to convert ldl/stl to cpu_physical_memory_read/write. > > > > > > > > > > > > I don't see how it would help. These still get target_phys_addr_t which > > > > is per-target. Further, a ton of devices do > > > > cpu_register_physical_memory/qemu_register_coalesced_mmio. > > > > These are also per target. > > > > > > I don't know what I was eating yesterday: there are no references to > > > ldl/stl in either rtl8139 or e1000. In fact, the conversion is simple > > > for the device itself, just add a property "be". The attached patch > > > performs this part. > > > > > > But now there is a bigger problem, how to pass the property to the > > > device. It's not fair to require the user to remember to set it. > > > > > > I still don't fully understand how come e1000 cares about > > target endianness. > > It shouldn't. Maybe the real fix is to remove the byte swapping. Presumably it's there for a reason? > > > > A simple solution would be to change all of cpu_XX functions to > > > > get a 64 bit address. This is a lot of churn, if we do this > > > > anyway we should also pass length to callbacks, this way > > > > rwhandler will get very small or go away completely. > > > > > > It's not too much effort to keep the target_phys_addr_t type. > > > > > > I don't understand - target_phys_addr_t is different for different > > targets to we will need to recompile the code for each target. > > What am I missing? > > target_phys_addr_t is 64 bit on a 64 bit host, on a 32 bit host it's > size will be either 64 or 32 bits depending on the target. So the > files are compiled once on 64 bit host, twice on 32 bit host if both > 32 and 64 bits targets are selected. How about just making it 64 bit unconditionally? How much do we save by using a 32 bit address value? -- MST