From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzoTE-0006rl-P1 for qemu-devel@nongnu.org; Tue, 02 Jun 2015 11:51:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzoTB-0000gu-Cw for qemu-devel@nongnu.org; Tue, 02 Jun 2015 11:51:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzoTB-0000go-4G for qemu-devel@nongnu.org; Tue, 02 Jun 2015 11:51:13 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id A2FE5B7CDD for ; Tue, 2 Jun 2015 15:51:12 +0000 (UTC) Message-ID: <556DD0ED.8010609@redhat.com> Date: Tue, 02 Jun 2015 18:51:09 +0300 From: Marcel Apfelbaum MIME-Version: 1.0 References: <1432568042-19553-1-git-send-email-marcel@redhat.com> <1432568042-19553-24-git-send-email-marcel@redhat.com> <20150531181221.GJ5268@redhat.com> <556C2985.9000909@redhat.com> <1433158819.19671.23.camel@nilsson.home.kraxel.org> <20150601141532-mutt-send-email-mst@redhat.com> <556C4E3F.7050102@redhat.com> <20150601142731-mutt-send-email-mst@redhat.com> <556C5881.8070605@redhat.com> <556C5E14.6090503@redhat.com> <556C62B7.5080305@redhat.com> <556C7C39.6000201@redhat.com> <556D9570.5070309@redhat.com> <556DCAC9.7070105@redhat.com> In-Reply-To: <556DCAC9.7070105@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V7 23/24] apci: fix PXB behaviour if used with unsupported BIOS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , "Michael S. Tsirkin" Cc: pbonzini@redhat.com, Gerd Hoffmann , qemu-devel@nongnu.org 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 >>>>> >>>> >>> >> >