Re: [Qemu-devel] [RFC 0/9] generate dynamic _CRS for motherboard resources

[Michael S. Tsirkin]

On Mon, Feb 17, 2014 at 11:46:13AM +0100, Gerd Hoffmann wrote:
> On Mo, 2014-02-17 at 12:28 +0200, Michael S. Tsirkin wrote:
> > On Mon, Feb 17, 2014 at 09:32:35AM +0100, Gerd Hoffmann wrote:
> > > On So, 2014-02-16 at 17:53 +0200, Michael S. Tsirkin wrote:
> > > > On Fri, Feb 07, 2014 at 01:51:27PM +0100, Igor Mammedov wrote:
> > > > > Since introduction of PCIHP, it became problematic to
> > > > > punch hole in PCI0._CRS statically since PCI hotplug
> > > > > region size became runtime changeable.
> > > > 
> > > > What makes it runtime changeable?
> > > 
> > > machine type.  q35 / piix map them at different locations.
> > 
> > That's not dynamic.  We can load the correct ones per DSDT.
> > 
> > > Also we might want to this also for devices which are
> > > runtime-configurable (isa-debugcon, pvpanic, ...).
> > 
> > That's more convincing, but I don't want
> > knowledge of all these devices in acpi-build.
> > Also we need to make seabios avoid these ranges
> > when enumerating devices.
> > How does it know to avoid them ATM?
> 
> seabios maps io ports @ 0xc000 up.
> recently it has changed to use 0x1000 -> 0xa000 region
> in case the hole above 0xc000 is too small.
> 
> In other words: It doesn't map anything below 0x1000 and it avoids
> 0xa000 -> 0xbfff.  Hardcoded.  I want lift the later restriction on q35,
> by moving pmbase (0xb000 atm) out of the way, so seabios can use the
> whole 0x1000 -> 0xffff range, but that is still wip.
> 
> cheers,
>   Gerd
> 

okay so we'll want some fwcfg for that correct?
whatever fills that, can share logic with acpi
generation :)

That might or might not make it dynamic enough to make it worth
bothering - alternative is just two version of acpi
depending on machine type.

-- 
MST