From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [RFC v2 01/20] Hierarchical memory region API Date: Tue, 28 Jun 2011 16:36:26 +0300 Message-ID: <4E09D8DA.3000606@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" To: Peter Maydell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19623 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756557Ab1F1Ngg (ORCPT ); Tue, 28 Jun 2011 09:36:36 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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