From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2ebp-0007EE-TX for qemu-devel@nongnu.org; Wed, 10 Jun 2015 07:55:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2ebl-0003bQ-0G for qemu-devel@nongnu.org; Wed, 10 Jun 2015 07:55:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2ebk-0003bF-PA for qemu-devel@nongnu.org; Wed, 10 Jun 2015 07:55:48 -0400 Message-ID: <557825C0.50603@redhat.com> Date: Wed, 10 Jun 2015 14:55:44 +0300 From: Marcel Apfelbaum MIME-Version: 1.0 References: <5572347E.1030105@redhat.com> <5577FEB3.4070600@redhat.com> <557819A6.4040707@redhat.com> In-Reply-To: <557819A6.4040707@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] PXB fixes for QEMU, and extra root buses for OVMF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , qemu devel list , edk2-devel list , Marcel Apfelbaum , Michael Tsirkin , "Gabriel L. Somlo (CMU)" On 06/10/2015 02:04 PM, Laszlo Ersek wrote: > On 06/10/15 11:09, Marcel Apfelbaum wrote: >> On 06/06/2015 02:45 AM, Laszlo Ersek wrote: > >>> (7) At least one issue remains to be solved (designed) in QEMU, for b= oth >>> SeaBIOS's and OVMF's sake: booting off devices that are located= on >>> the PXB. The problem is with the "bootorder" fw_cfg file. Consi= der >>> the following example: >>> >>> /pci@i0cf8/scsi@3/channel@0/disk@0,0 >>> /pci/pci-bridge@0/ethernet@2/ethernet-phy@0 >>> >>> which is generated for the options >>> >>> -device virtio-scsi-pci,id=3Dscsi0 \ >>> -device scsi-cd,bus=3Dscsi0.0,drive=3Dcdrom,bootindex=3D0 \ >>> \ >>> -device pxb,id=3Dbridge1,bus_nr=3D4 \ >>> -device >>> e1000,netdev=3Dnetdev0,bus=3Dbridge1,addr=3D2,romfile=3D,bootindex=3D= 1 >>> >>> While the first entry is recognized by both SeaBIOS and OVMF, t= he >>> second entry (generated for the NIC hanging off the PXB, see ab= ove) >>> is recognized by neither. (I tested OVMF, and investigated the >>> SeaBIOS source, for this claim.) >>> >>> For the SeaBIOS explanation, grep the source code for FW_PCI_DO= MAIN. >> Thanks for bringing it to my attention. >> >>> >>> The OVMF explanation is that OVMF simply rejects the initial >>> OpenFirmware device path node "/pci" with a controlled parse er= ror >>> (as opposed to the "/pci@i0cf8" node, which it recognizes and >>> translates to UEFI in combination with the rest of that OFW dev= ice >>> path). >>> >>> The "/pci" node comes from QEMU's sysbus_get_fw_dev_path() func= tion, >>> file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) a= nd >>> (s->num_pio) branches apply. (The (s->num_pio) branch applies f= or >>> the first entry, ie. "/pci@i0cf8".) >>> >>> Something has to be invented here to clue in both firmwares as = to >>> the root bus number (here bus_nr=3D4), in a format that is comp= liant >>> with the "OpenFirmware unit address" concept. (Note that >>> "/pci-bridge@0" only gives away the slot number *on* the extra = root >>> bus, not the number of the root bus itself.) For example: >>> >>> /pci@rootbus4/pci-bridge@0/ethernet@2/ethernet-phy@0 >>> >>> would be acceptable. However, I don't know how to implement thi= s in >>> sysbus_get_fw_dev_path(). >> I'll look into it. What is the OpenFirmware unit address" concept ? :) > > Okay, I looked it up again (also rechecked the OVMF parser code) -- in > fact the example I gave would not be preferable. > > * Background: > > For the specification, please see "3.2.1.1 Node names" in > > IEEE Standard for Boot (Initialization Configuration) > Firmware: Core Requirements and Practices > > The notation is > > driver-name@unit-address:device-arguments > > It says (excerpt): > > The /driver name/ field is a sequence of between one and 31 letters, > digits, and punctuation characters from the set =E2=80=9C, . _ + - =E2= =80=9D. > Uppercase and lowercase characters are distinct. [...] > > [...] > > The /unit address/ field is the text representation of the physical > address of the device within the address space defined by its parent > node. The form of the text representation is bus-dependent. > > Please see the TranslatePciOfwNodes() function in OVMF, for the > "PCI-like" OFW device paths that OVMF currently recognizes -- just > scroll through the function to see the comments: > > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuBootO= rderLib/QemuBootOrderLib.c#L582 > > * Therefore, the only kind of /unit address/ that OVMF has faced, > exposed by QEMU, is "comma separated list of hexadecimal integers". OVM= F > uses the helper function ParseUnitAddressHexList() to parse them. (It i= s > defined in the same file linked above.) > > It would be preferable to stick with this assumption. Therefore, let me > revise my earlier recommendation, and ask for: > > /pxb@4/pci-bridge@0/ethernet@2/ethernet-phy@0 > ^ > bus_nr (hex, without 0x prefix) > > instead. Providing "pxb" as /driver name/ in the very first OFW node > would be sufficient for OVMF (and I guess for SeaBIOS too) to recognize > the extra root bus. The single hex integer in the /unit address/ of the > first node would identify bus_nr. The rest of the nodes in the OFW > devpath are already recognized by OVMF. > > An alternative would be simply > > /pci@4 > > (quoting just the first node), because I can still tell apart the > numeric ("4") /unit address/ from the "i0cf8" one that identifies the > main root bus. > > Summary: either of the following would be okay: > > /pxb@4 > /pci@4 Thanks a lot for the pointer. I prefer the latest. I'll get to it. Thanks, Marcel > > Thanks > Laszlo >