On Wed, Jul 24, 2019 at 03:14:39PM +0800, Peter Xu wrote: > On Tue, Jul 23, 2019 at 11:26:18AM -0600, Alex Williamson wrote: > > > On 3/29/19 11:49 AM, Alex Williamson wrote: > > > > [Cc +Brijesh] > > > > > > > > Hi Brijesh, will the change below require the IVRS to be updated to > > > > include aliases for all BDF ranges behind a conventional bridge? I > > > > think the Linux code handles this regardless of the firmware provided > > > > aliases, but is it required per spec for the ACPI tables to include > > > > bridge aliases? Thanks, > > > > > > > > > > We do need to includes aliases in ACPI table. We need to populate the > > > IVHD type 0x43 and 0x4 for alias range start and end. I believe host > > > IVRS would contain similar information. > > > > > > Suravee, please correct me if I am missing something? > > > > I finally found some time to investigate this a little further, yes the > > types mentioned are correct for defining start and end of an alias > > range. The challenge here is that these entries require a DeviceID, > > which is defined as a BDF, AIUI. The IVRS is created in QEMU, but bus > > numbers are defined by the guest firmware, and potentially redefined by > > the guest OS. This makes it non-trivial to insert a few IVHDs into the > > IVRS to describe alias ranges. I'm wondering if the solution here is > > to define a new linker-loader command that would instruct the guest to > > write a bus number byte to a given offset for a described device. > > These commands would be inserted before the checksum command, such that > > these bus number updates are calculated as part of the checksum. > > > > I'm imagining the command format would need to be able to distinguish > > between the actual bus number of a described device, the secondary bus > > number of the device, and the subordinate bus number of the device. > > For describing the device, I'm envisioning stealing from the DMAR > > definition, which already includes a bus number invariant mechanism to > > describe a device, starting with a segment and root bus, follow a chain > > of devfns to get to the target device. Therefore the guest firmware > > would follow the path to the described device, pick the desired bus > > number, and write it to the indicated table offset. > > > > Does this seem like a reasonable approach? Better ideas? I'm not > > thrilled with the increased scope demanded by IVRS support, but so long > > as we have an AMD IOMMU model, I don't see how to avoid it. Thanks, > > I don't have a better idea yet, but just want to say that accidentally > I was trying to look into this as well starting from this week and I'd > say that's mostly what I thought about too (I was still reading a bit > seabios when I saw this email)... so at least this idea makes sense to > me. > > Would the guest OS still change the PCI bus number even after the > firmware (BIOS/UEFI)? Could I ask in what case would that happen? > > Thanks,
Guest OSes can in theory rebalance resources. Changing bus numbers would be useful if new bridges are added by hotplug. In practice at least Linux doesn't do the rebalancing. I think that if we start reporting PNP OS support in BIOS then windows might start doing that more aggressively. > -- > Peter Xu