From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2uKl-0005tB-Ec for qemu-devel@nongnu.org; Thu, 11 Jun 2015 00:43:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2uKi-0000Hb-A3 for qemu-devel@nongnu.org; Thu, 11 Jun 2015 00:43:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2uKi-0000HT-4D for qemu-devel@nongnu.org; Thu, 11 Jun 2015 00:43:16 -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 14BA83173E7 for ; Thu, 11 Jun 2015 04:43:14 +0000 (UTC) Message-ID: <557911E0.6000208@redhat.com> Date: Thu, 11 Jun 2015 07:43:12 +0300 From: Marcel Apfelbaum 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; format=flowed 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: Laszlo Ersek , qemu-devel@nongnu.org Cc: Markus Armbruster , "Michael S. Tsirkin" On 06/10/2015 10:34 PM, 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. :) > > The SeaBIOS side I'll probably leave to you... /me ducks :) I'll take it, sure, you are doing all the work anyway :) Thanks, Marcel > > Thanks > Laszlo >