From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbXgo-0001Au-8a for qemu-devel@nongnu.org; Tue, 28 Jun 2011 08:46:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbXgm-0003gs-MC for qemu-devel@nongnu.org; Tue, 28 Jun 2011 08:46:49 -0400 Received: from david.siemens.de ([192.35.17.14]:18280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbXgm-0003gK-4d for qemu-devel@nongnu.org; Tue, 28 Jun 2011 08:46:48 -0400 Message-ID: <4E09CD33.70704@siemens.com> Date: Tue, 28 Jun 2011 14:46:43 +0200 From: Jan Kiszka 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: <4E09C482.6050508@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Avi Kivity Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 2011-06-28 14:09, Avi Kivity wrote: > On 06/28/2011 03:07 PM, Jan Kiszka wrote: >>> >>> The point is that different buses have different widths. >>> target_phys_addr_t matches just one bus in the system. It needs to be >>> the maximum size of all buses present to be useful. >> >> Then we need a type for that. Or we need to demand that >> target_phys_addr_t is defined large enough to support all buses that the >> particular arch wants to address. Hardcoding 64 bit or anything is not >> appropriate for a generic subsystem. > > Okay, let's make t_p_a_t max(bus size in system). Do we have 32-bit > targets that don't support pci (I guess, pc-isa with cpu < ppro?). At least lm32 and microblaze appear to fall into that category. > Do we want to support a 32-bit variant of pci? It certainly existed at > some point. As long as making everything 64 bit in the implementation of the device models is not guest visible, I don't think that should be a problem. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux