From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC v2 01/20] Hierarchical memory region API Date: Tue, 28 Jun 2011 14:07:18 +0200 Message-ID: <4E09C3F6.8010702@siemens.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" To: Avi Kivity Return-path: In-Reply-To: <4E09C0B2.3030101@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 2011-06-28 13:53, Avi Kivity wrote: > 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. 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux