On 06/02/15 13:37, Marcel Apfelbaum wrote: > On 06/01/2015 06:37 PM, Laszlo Ersek wrote: >> 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. > > Hi Laszlo, > I am sorry for the late reply. > Can you please check using mst branch? > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git pxb > Just add to the regular command line: > -device pxb,id=bridge1,bus_nr=4 -netdev user,id=u -device > e1000,id=net2,bus=bridge1,netdev=u,addr=1 > > Thanks a lot for the help, we mainly want to know if there is > an architecture issue that will prevent the PXB to work with OVMF. > Marcel
I wrote a horrible patch that allowed OVMF to enumerate the e1000 NIC on the pxb, so I guess there should be no "architectural issue" preventing OVMF from using this device. Of course, making good / dynamic use of this stuff is light years away. I'll respond with more details in the thread you started on edk2-devel: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15147 Thanks Laszlo >>> >>>> Second, recently I tested OVMF on Q35, but not just with a simple / >>>> usual command line invocation -- I tested it on a Q35 machine >>>> configured >>>> by libvirt. That's a very different animal. >>>> >>>> While it exposed a problem in OVMF's own boot order processing: >>>> >>>> https://github.com/tianocore/edk2/commit/feca17fa4b >>>> >>>> I was surprised to see that the PCI bus driver enumerated devices >>>> behind >>>> two bridges no less without any problems. So, bridges off the one root >>>> bridge should work, but several root bridges probably won't. (Exposing >>>> root bridges is the responsibility of another driver, and they are not >>>> enumerable in the usual way.) >>>> >>>> Thanks >>>> Laszlo >>>> >>> >> >
