Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	hangaohuai@huawei.com,
	Alexander Spyridakis <a.spyridakis@virtualopensystems.com>,
	Mark Salter <msalter@redhat.com>,
	Claudio Fontana <claudio.fontana@huawei.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	Shannon Zhao <zhaoshenglong@huawei.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Shannon Zhao <shannon.zhao@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM
Date: Wed, 8 Apr 2015 20:50:08 +0200	[thread overview]
Message-ID: <20150408204642-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <20150407153557.3b2a5713@igors-macbook-pro.local>

On Tue, Apr 07, 2015 at 03:35:57PM +0200, Igor Mammedov wrote:
> On Tue, 7 Apr 2015 13:07:31 +0100
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> > On 7 April 2015 at 03:43, Shannon Zhao <zhaoshenglong@huawei.com>
> > 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
> > 