On 06/01/15 15:48, Marcel Apfelbaum wrote:
On 06/01/2015 04:28 PM, Laszlo Ersek wrote:
On 06/01/15 15:05, Marcel Apfelbaum wrote:
On 06/01/2015 03:27 PM, Michael S. Tsirkin wrote:
On Mon, Jun 01, 2015 at 03:21:19PM +0300, Marcel Apfelbaum wrote:
On 06/01/2015 03:17 PM, Michael S. Tsirkin wrote:
On Mon, Jun 01, 2015 at 01:40:19PM +0200, Gerd Hoffmann wrote:
On Mo, 2015-06-01 at 12:44 +0300, Marcel Apfelbaum wrote:
On 05/31/2015 09:12 PM, Michael S. Tsirkin wrote:
On Mon, May 25, 2015 at 06:34:01PM +0300, Marcel Apfelbaum wrote:
PXB does not work with unsupported bioses, but should
not interfere with normal OS operation.
We don't ship them anymore, but it's reasonable
to keep the work-around until we update the bios in qemu.
We already did, did we not?
Yes, we did, but Gerd preferred to keep this patch around.
Adding him to thread.
seabios bundled with qemu isn't the only possible firmware.
We have ovmf, coreboot, qboot.
ovmf is especially interesting. Marcel, did you look at what
happens with pxb and ovmf?
No, I talked to Laszlo about it, he said ovmf is not there yet.
OVMF will not query the extra buses, so the devices on the extra bus
will not be visible.
Adding him to the thread.
Thanks,
Marcel
But does OVMF need this specific patch?
I don't think so because more than likely it doesn't scan for the extra
buses,
so it will not try to configure these devices.
Laszlo, am I right?
Well, I don't know. :)
First, I'm not seeing the specific patch in question (can you pls send
me a URL into the web archive, or a Message-Id?)
Well, there are a few patches, all this series,
You can look for patches:
13/24 hw/acpi: add support for i440fx 'snooping' root busses -> acpi
declarations
18/24 hw/pci: introduce PCI Expander Bridge (PXB)
19/24 hw/pci: inform bios if the system has extra pci root buses
Basically we add the pxb resources to ACPI tables and then inform BIOS
using
etc/extra-pci-roots fw_config file that he has extra roots to scan.
If the OVMF only looks for bus 0 and does not scan all possible buses
it will not see PXB's root bus
I don't know enough about PCI to reply sensibly.
I can tell you that the bus range in OVMF, from "mResAperture" in
"PcAtChipsetPkg/PciHostBridgeDxe/PciHostBridge.c", is [0..0xff], inclusive.
This bus range is then exposed in the function StartBusEnumeration() to
the caller (which is the PCI bus driver), as an output parameter. The
StartBusEnumeration() function has the following leading comment:
Sets up the specified PCI root bridge for the bus enumeration process.
This member function sets up the root bridge for bus enumeration and
returns the PCI bus range over which the search should be performed
in ACPI 2.0 resource descriptor format.
So, there's a chance that if those busses actually exist on the virtual
hardware, the drivers included by OVMF from the generic edk2 source
"will just work". It is also possible that OVMF will notice no change at
all.
Do you have a public branch, and a matching command line? The PCI
enumeration / resource allocation spews a bunch of messages in OVMF, so
if you placed (on the QEMU command line) some devices on one of these
nonzero buses, then their enumeration / resource allocation, determined
from the log, could serve as evidence. (I think this should be testable
on a non-NUMA host, and without passthrough devices as well.)
Also, I checked the actual code hunks & message body for this patch (ie.
23/24) on the web. Looks like I should be able to dump the ACPI tables
in the guest, and get those dumps to you for verification. OVMF does
delay the ACPI download until after PCI enumeration, so the state of the
guest _CRS would be (negative or positive) proof, not lack of proof.