Re: [PATCH] pci hotplug: rescan bridge after device hotplug

[Jason Baron <jbaron@redhat.com>]

On Wed, May 23, 2012 at 10:16:06AM -0700, Yinghai Lu wrote:
> On Wed, May 23, 2012 at 8:53 AM, Jason Baron <jbaron@redhat.com> wrote:
> >> > but still would prefer you to make qemu to support pciehp.
> >>
> >> another solution could be:
> >>
> >> in qemu acpi dsdt, you could set bridge size for new added bridge.
> >>
> >> current pbus_size_mem() will not shrink the old bridge resource size.
> >
> > ok, I also tried hard-wiring the bridge io/mem base and limit registers on the
> > qemu side. That seems to work without any guest-side hotplug code changes. And
> > would seem to be more flexible than putting the limits in acpi.
> 
> that should be acpi asl code or SMI work. and should make sure that
> range is not overlapped with resources that are used by other bridges
> and pci devices.
> 

Ok. So you are saying to define a 'Name (_CRS, ResourceTemplate() {
Memory() IO() })' block for each bridge? The acpi code I currently have,
has one 'Device()' definition for each top-level hotplug slot. Would it
be ok to have the '_CRS' apply to either one?

Also, I'm wondering where in the acpiphp code it picks up the memory/io
ranges to configure them as bridge ranges?

I also see in ACPIspec40a.pdf, section "9.11 Module Device":

"
If no _CRS object is present, OSPM will assume that the module device is
a simple container object that does not produce the resources consumed by its
child devices. In this case, OSPM will assign resources to the child devices as
if they were direct children of the module device's parent object.
"

So not sure if that applies to hotplug, but that is not what acpiphp is
doing atm.

Finally, I don't see why putting the bridge window range logic into qemu is a
bad solution. Qemu knows memory ranges consumed by various resoures,
looking at 'info mtree', so why can't qemu hand out the bridge ranges
dynamically? In that way, it can re-size the windows more optimally than
something hard-coded into acpi. So to me, it seems like a better
approach.

Thanks,

-Jason