On Wed, Jun 01, 2011 at 11:20:29PM +0900, Isaku Yamahata wrote:
> On Wed, Jun 01, 2011 at 09:30:12AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> >> 0xE0000000 is hard-coded in the DSDT for both piix and q35 as below.
> >> If the range is determined dynamically, the area also needs to be
> >> updated somehow dynamically.
> >>
> >> ...
> >> Name (_CRS, ResourceTemplate ()
> >> ...
> >> DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
> >> 0x00000000, // Address Space Granularity
> >> 0xE0000000, // Address Range Minimum
> >> 0xFEBFFFFF, // Address Range Maximum
> >> 0x00000000, // Address Translation Offset
> >> 0x1EC00000, // Address Length
> >> ,, , AddressRangeMemory, TypeStatic)
> >
> > Uhm, indeed. I know next to nothing about ACPI though. Ideas anyone
> > how this could be done?
>
> Right now what I can think of is.
> It would be possible to know the offset in AmlCode[] by
> compiling dsl with -l option. The we can get the mix of source and
> resulted hex with offset like
It's easier then this - as Avi indicated, one can turn _CRS into a
method which returns the current info with the PCI size filled in at
runtime. Something like:
Method (_CRS, 0, NotSerialized) {
Name (TMP, ResourceTemplate ()
{
...
})
CreateDWordField (TMPM, 0x123, TMP)
Store (TMPM, PCIM)
Return (TMP)
}
This is already done for other devices - see \SB.LNKS._CRS. For this
to work, the new variable PCIM needs to be set to the size of the PCI
region, which can be populated in the SSDT when it is built by
SeaBIOS.
As Jan points out though, is a dynamic PCI region really needed?
Those that need a large PCI region are also likely to need a large
amount of memory. Maybe the space for PCI should just be increased.
-Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
