From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2elj-0007YV-O1 for qemu-devel@nongnu.org; Wed, 10 Jun 2015 08:06:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2elg-00006z-G6 for qemu-devel@nongnu.org; Wed, 10 Jun 2015 08:06:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2elf-00005N-Ma for qemu-devel@nongnu.org; Wed, 10 Jun 2015 08:06:04 -0400 Message-ID: <55782826.3050409@redhat.com> Date: Wed, 10 Jun 2015 14:05:58 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <5572347E.1030105@redhat.com> <5577FEB3.4070600@redhat.com> <557819A6.4040707@redhat.com> <557825C0.50603@redhat.com> In-Reply-To: <557825C0.50603@redhat.com> Content-Type: text/plain; charset=utf-8 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: Marcel Apfelbaum , qemu devel list , edk2-devel list , Marcel Apfelbaum , Michael Tsirkin , "Gabriel L. Somlo (CMU)" On 06/10/15 13:55, Marcel Apfelbaum wrote: > 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 >>>> both >>>> SeaBIOS's and OVMF's sake: booting off devices that are >>>> located on >>>> the PXB. The problem is with the "bootorder" fw_cfg file. >>>> Consider >>>> 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, = the >>>> second entry (generated for the NIC hanging off the PXB, see >>>> above) >>>> 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_DOMAIN. >>> 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 >>>> error >>>> (as opposed to the "/pci@i0cf8" node, which it recognizes and >>>> translates to UEFI in combination with the rest of that OFW >>>> device >>>> path). >>>> >>>> The "/pci" node comes from QEMU's sysbus_get_fw_dev_path() >>>> function, >>>> file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) = and >>>> (s->num_pio) branches apply. (The (s->num_pio) branch applies = for >>>> 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 >>>> compliant >>>> 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 >>>> this 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 paren= t >> 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/QemuBoot= OrderLib/QemuBootOrderLib.c#L582 >> >> >> * Therefore, the only kind of /unit address/ that OVMF has faced, >> exposed by QEMU, is "comma separated list of hexadecimal integers". OV= MF >> uses the helper function ParseUnitAddressHexList() to parse them. (It = is >> defined in the same file linked above.) >> >> It would be preferable to stick with this assumption. Therefore, let m= e >> 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 recogniz= e >> the extra root bus. The single hex integer in the /unit address/ of th= e >> 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. Indeed, the current initial node that is produced for the nonzero root buses is "/pci", so the "only" part you need to append to them is "@bus_nr". :) Thanks! Laszlo > I'll get to it. >=20 > Thanks, > Marcel >=20 >> >> Thanks >> Laszlo >> >=20