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
--
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
