qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose i


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM
Date: Tue, 7 Apr 2015 15:35:57 +0200

On Tue, 7 Apr 2015 13:07:31 +0100
Peter Maydell <address@hidden> wrote:

> On 7 April 2015 at 03:43, Shannon Zhao <address@hidden>
> 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.
 

> 
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]