From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbWrB-0004tC-0G for qemu-devel@nongnu.org; Tue, 28 Jun 2011 07:53:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbWr9-0002hQ-Hv for qemu-devel@nongnu.org; Tue, 28 Jun 2011 07:53:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbWr8-0002hD-VZ for qemu-devel@nongnu.org; Tue, 28 Jun 2011 07:53:27 -0400 Message-ID: <4E09C0B2.3030101@redhat.com> Date: Tue, 28 Jun 2011 14:53:22 +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> In-Reply-To: <4E09ACD2.9070907@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Jan Kiszka Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, "Michael S. Tsirkin" On 06/28/2011 01:28 PM, Jan Kiszka wrote: > On 2011-06-28 12:03, Michael S. Tsirkin wrote: > >> +struct MemoryRegion { > >> + /* All fields are private - violators will be prosecuted */ > >> + const MemoryRegionOps *ops; > >> + MemoryRegion *parent; > >> + uint64_t size; > >> + target_phys_addr_t addr; > >> + target_phys_addr_t offset; > >> + ram_addr_t ram_addr; > >> + bool has_ram_addr; > >> + MemoryRegion *alias; > >> + target_phys_addr_t alias_offset; > >> + unsigned priority; > >> + bool may_overlap; > >> + QTAILQ_HEAD(subregions, MemoryRegion) subregions; > >> + QTAILQ_ENTRY(MemoryRegion) subregions_link; > >> + QTAILQ_HEAD(coalesced_ranges, CoalescedMemoryRange) coalesced; > >> + const char *name; > > > > I'm never completely sure whether these should be target addresses > > or bus addresses or just uint64_t. > > With pci on a 32 bit system you can stick a 64 bit address > > in a BAR and the result will be that it is never accessed > > from the CPU. > > > > Memory regions are not bound to any current or future PCI > specifications. Any fixed bit width would be wrong here, ie. size should > rather be target_phys_addr_t. 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. -- error compiling committee.c: too many arguments to function