From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbYIg-0001ri-Mo for qemu-devel@nongnu.org; Tue, 28 Jun 2011 09:26:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbYIe-0001du-NJ for qemu-devel@nongnu.org; Tue, 28 Jun 2011 09:25:58 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:36041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbYIe-0001dj-C9 for qemu-devel@nongnu.org; Tue, 28 Jun 2011 09:25:56 -0400 Received: by pzk9 with SMTP id 9so153214pzk.33 for ; Tue, 28 Jun 2011 06:25:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E09C482.6050508@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> Date: Tue, 28 Jun 2011 14:25:54 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Avi Kivity Cc: Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" 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. >=C2=A0Do we have 32-bit targets > that don't support pci (I guess, pc-isa with cpu < ppro?). =C2=A0Do we wa= nt to > support a 32-bit variant of pci? =C2=A0It 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). -- PMM