On Wed, May 23, 2012 at 01:31:23PM -0700, Yinghai Lu wrote: > On Wed, May 23, 2012 at 11:44 AM, Jason Baron <jbaron@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx> 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. > > _CRS is only used for pci root bus. > > I mean in you _PS0 in your socket. > > > > > 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. > > acpi could be dynamically too. > > Yinghai There isn't much you can do besides loading a new table, is there? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html