From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfv3Q-0005vA-Mp for qemu-devel@nongnu.org; Wed, 08 Apr 2015 14:50:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yfv3M-0000Ol-Bt for qemu-devel@nongnu.org; Wed, 08 Apr 2015 14:50:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yfv3M-0000OZ-4q for qemu-devel@nongnu.org; Wed, 08 Apr 2015 14:50:20 -0400 Date: Wed, 8 Apr 2015 20:50:08 +0200 From: "Michael S. Tsirkin" Message-ID: <20150408204642-mutt-send-email-mst@redhat.com> References: <1428055432-12120-1-git-send-email-zhaoshenglong@huawei.com> <1428346052.2973.26.camel@deneb.redhat.com> <55234469.9060404@huawei.com> <20150407153557.3b2a5713@igors-macbook-pro.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150407153557.3b2a5713@igors-macbook-pro.local> Subject: Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Peter Maydell , hangaohuai@huawei.com, Alexander Spyridakis , Mark Salter , Claudio Fontana , QEMU Developers , "Huangpeng (Peter)" , Hanjun Guo , Shannon Zhao , Paolo Bonzini , Laszlo Ersek , Christoffer Dall , Shannon Zhao On Tue, Apr 07, 2015 at 03:35:57PM +0200, Igor Mammedov wrote: > On Tue, 7 Apr 2015 13:07:31 +0100 > Peter Maydell wrote: > > > On 7 April 2015 at 03:43, Shannon Zhao > > wrote: > > > The ACPI table entry: > > > Method (_CBA, 0, NotSerialized) // _CBA: Configuration > > > Base Address { > > > Return (0x3F000000) > > > } > > > Method (_CRS, 0, NotSerialized) // _CRS: Current > > > Resource Settings { > > > Name (RBUF, ResourceTemplate () > > > { > > > WordBusNumber (ResourceProducer, MinFixed, > > > MaxFixed, PosDecode, 0x0000, // Granularity > > > 0x0000, // Range Minimum > > > 0x000F, // Range Maximum > > > 0x0000, // Translation Offset > > > 0x0010, // Length > > > ,, ) > > > DWordMemory (ResourceProducer, PosDecode, > > > MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // > > > Granularity 0x10000000, // Range Minimum > > > 0x3EFF0000, // Range Maximum > > > 0x00000000, // Translation Offset > > > 0x2EFF0000, // Length > > > > In all the other sections, the Length entry is (rangemax - rangemin) > > + 1, but in this one it is not, which suggests an error. Probably your > > rangemax here is wrong, since 0x3eff0000 is actually the first address > > in the IO window. > > > > (If ACPI is effectively describing the length of the range in > > two separate places, it's a shame it doesn't sanity check that > > they both agree...) > According to spec Range Minimum & Range Maximum are > lowest/highest possible base address > and have nothing to do with range size. > In x86 target that insanity was since the beginning, I guest it works > because no OS tries to use anything other than Range Minimum. > For example If guest has mapped region at Range Maximum, then access to > it would go beyond on real memory region mapped in QEMU. > > In general Range Minimum & Range Maximum should be the same unless > HW side covers access up to Range Maximum + Length. > I think it's because the same structure can be used to define memory resources for devices with programmable base addresses (e.g. like PCI). Thus you can separately define range of base addresses (legal BAR values) and separately - the length that is claimed by the BAR (BAR size). OTOH IIUC if base address is not programmable, min and max must always be the same since it's the only valid value. > > > > -- PMM > >