From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2mLU-0004Iw-1S for qemu-devel@nongnu.org; Wed, 10 Jun 2015 16:11:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2mLQ-0002vT-NF for qemu-devel@nongnu.org; Wed, 10 Jun 2015 16:11:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2mLQ-0002vG-Fn for qemu-devel@nongnu.org; Wed, 10 Jun 2015 16:11:28 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id AF851C016B for ; Wed, 10 Jun 2015 20:11:27 +0000 (UTC) Message-ID: <557899EB.2030206@redhat.com> Date: Wed, 10 Jun 2015 22:11:23 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1433956033-11584-1-git-send-email-lersek@redhat.com> <1433956033-11584-5-git-send-email-lersek@redhat.com> <55788F80.2060404@redhat.com> <55789129.1010403@redhat.com> In-Reply-To: <55789129.1010403@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum , qemu-devel@nongnu.org Cc: Markus Armbruster , "Michael S. Tsirkin" On 06/10/15 21:34, Laszlo Ersek wrote: > On 06/10/15 21:26, Marcel Apfelbaum wrote: >> On 06/10/2015 08:07 PM, Laszlo Ersek wrote: >>> The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot >>> off devices behind the PXB. This happens because the >>> sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have >>> enough information to format a unique identifier for the PXB in question, >>> and consequently the OpenFirmware device path passed down to the guest >>> firmware in the "bootorder" fw_cfg file is unusable for identifying the >>> boot device. >>> >>> For example, the command line fragment >>> >>> -device pxb,id=bridge1,bus_nr=4 \ >>> \ >>> -netdev user,id=netdev0 \ >>> -device e1000,netdev=netdev0,bus=bridge1,addr=2,bootindex=0 >>> >>> results in the following "bootorder" entry: >>> >>> /pci/pci-bridge@0/ethernet@2/ethernet-phy@0 >>> >>> The initial "pci" node is formatted by sysbus_get_fw_dev_path(), and the >>> resultant OpenFirmware device path is independent of bus_nr=4 -- and >>> therefore it is useless for identifying the device. >>> >>> In this patch we insert a dummy bus between the main sysbus and the >>> TYPE_PXB_HOST device. Formatting child addresses is a bus class level >>> responsibility, which is exactly what we'll use here. >>> >>> After the patch, the same command line fragment results in the following >>> OpenFirmware device path in the "bootorder" fw_cfg file: >>> >>> /extra-pci-roots/pxbhost@4/pci-bridge@0/ethernet@2/ethernet-phy@0 >>> >>> The original, initial "/pci" fragment has been replaced with >>> "/extra-pci-roots/pxbhost@4", which (a) looks better, (b) provides all >>> the >>> necessary information. sysbus_get_fw_dev_path() formats the first node >>> ("extra-pci-roots") as always, and the new function >>> extra_pci_roots_bus_get_fw_dev_path() formats the second one >>> ("pxbhost@4"). >>> >>> Here's the comparison ("diff -u -b -U28") between the "info qtree" >>> outputs, before and after (the hpet device is the first common line): >> >> BTW, did you try to boot from it :) ? > > No, not yet; I'll have to write additional OVMF code for that; but the > syntax is OK, and the information is there, so I'm fairly sure I can > write that code. :) On a second thought -- I *will* write the OVMF code for this now, or tomorrow, because the syntax is *still* a little bit off. I think we'll need: /extra-pci-roots@0/pci-root@4/pci-bridge@0/ethernet@2/ethernet-phy@0 ^^ The part I marked (ie. the @ and the UnitAddress after it) are mandatory. I'll just hardcode the "@0" string there in QEMU, as written above. Thanks Laszlo > The SeaBIOS side I'll probably leave to you... /me ducks :) > > Thanks > Laszlo >