From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJiT4-00062Z-Aj for qemu-devel@nongnu.org; Thu, 04 Oct 2012 06:15:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJiSz-00007Y-8D for qemu-devel@nongnu.org; Thu, 04 Oct 2012 06:15:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJiSy-00006q-O9 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 06:15:40 -0400 Message-ID: <506D61C5.7070009@redhat.com> Date: Thu, 04 Oct 2012 12:15:33 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1349280245-16341-1-git-send-email-avi@redhat.com> <1349280245-16341-20-git-send-email-avi@redhat.com> <506D2EEE.3010904@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1 19/22] memory: per-AddressSpace dispatch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Michael S. Tsirkin" , liu ping fan , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Paolo Bonzini On 10/04/2012 10:47 AM, Peter Maydell wrote: >>> I'd make address_space_* use uint64_t instead of target_phys_addr_t >>> for the address. It may actually be buggy for 32 bit >>> target_phys_addr_t and 64 bit DMA addresses, if such architectures >>> exist. Maybe memory.c could be made target independent one day. > > I thought target_phys_addr_t was supposed to be "widest necessary > address", so an architecture with 64 bit DMA addresses should be > implemented with 64 bit target_phys_addr_t... Yes. Since even before this patchset all DMA went through the memory API (and before the memory API, through cpu_register_physical_memory), this case was already broken. > >> We can make target_phys_addr_t 64 bit unconditionally. The fraction of >> deployments where both host and guest are 32 bits is dropping, and I >> doubt the performance drop is noticable. > > I benchmarked it on ARM when I switched ARM to always 64 bit physaddrs; > it was just about measurable (maybe half a percent or so) but not > significant (we don't use this type in the fast path for memory > accesses, only in the slow/IO path). > > I'd favour just moving everything to 64 bits (the remaining > 32 bit targets are: cris, lm32, m68k, microblaze, or32, sh4, unicore32, > xtensa). However it does require some review of devices to check that > they're not using target_phys_addr_t when they meant uint32_t [eg > in registers for DMA devices] or relying on 32 bit wraparound. I posted a patch. I did no review, the cost/benefit tradeoff is horrible IMO, especially with me not knowing the details. If something breaks, git bisect will save the day. -- error compiling committee.c: too many arguments to function