From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbYSx-0004FD-Kj for qemu-devel@nongnu.org; Tue, 28 Jun 2011 09:36:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbYSw-0003a5-6c for qemu-devel@nongnu.org; Tue, 28 Jun 2011 09:36:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbYSv-0003Zx-Pn for qemu-devel@nongnu.org; Tue, 28 Jun 2011 09:36:34 -0400 Message-ID: <4E09D8DA.3000606@redhat.com> Date: Tue, 28 Jun 2011 16:36:26 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1309180927-19003-1-git-send-email-avi@redhat.com> <1309180927-19003-2-git-send-email-avi@redhat.com> <20110628100343.GA21866@redhat.com> <4E09ACD2.9070907@siemens.com> <4E09C0B2.3030101@redhat.com> <4E09C3F6.8010702@siemens.com> <4E09C482.6050508@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 06/28/2011 04:25 PM, Peter Maydell wrote: > On 28 June 2011 13:09, Avi Kivity wrote: > > Okay, let's make t_p_a_t max(bus size in system). > > If you want a type for that, can't you give it a sensible (ie > different) name? target_phys_addr_t is pretty clearly "the type > of a physical address for this target" and having it actually > be something else is just going to be confusing. "a physical address" is ambiguous. There are many physical addresses flowing around. Certainly it's most natural to think about the processor's physical address bus, but that's not always useful. Since all *devices* use target_phys_addr_t, I think we should just adopt that to avoid major and pointless churn. > > Do we have 32-bit targets > > that don't support pci (I guess, pc-isa with cpu< ppro?). Do we want to > > support a 32-bit variant of pci? It certainly existed at some point. > > As a thought experiment, you could take an existing 32 bit > target and define a new board model that happens to have eg a > new pci controller on it. It doesn't seem right that that > should cause the system's idea of this type width to change, > it's just a new device model and board. So if you have this > type I think it ought to be max(bus size of widest bus qemu > supports). That indicates typedef uint64_t target_phys_addr_t; -- error compiling committee.c: too many arguments to function