Re: [Qemu-devel] [PATCH V7 23/24] apci: fix PXB behaviour if used with unsupported BIOS

[Marcel Apfelbaum <marcel@redhat.com>]

On 06/02/2015 06:24 PM, Laszlo Ersek wrote:
> 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/15147ink

Hi Laszlo,
Those are wonderful news! Thank you very much for your involvement.
Once the above thread will lead to an actual design, maybe I can
contribute to the implementation.

Michael, since Laszlo succeeded to enumerate devices behind PXB,
I think we can finally merge this device into QEMU. Do you agree?

Thanks,
Marcel

>
> Thanks
> Laszlohttp://thread.gmane.org/gmane.comp.bios.tianocore.devel/15147
>
>
>>>>
>>>>> 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
>>>>>
>>>>
>>>
>>
>