[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] PXB fixes for QEMU, and extra root buses for OVMF
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] PXB fixes for QEMU, and extra root buses for OVMF |
Date: |
Wed, 10 Jun 2015 14:05:58 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
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:
>>>>
>>>> /address@hidden/address@hidden/address@hidden/address@hidden,0
>>>> /pci/address@hidden/address@hidden/address@hidden
>>>>
>>>> which is generated for the options
>>>>
>>>> -device virtio-scsi-pci,id=scsi0 \
>>>> -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \
>>>> \
>>>> -device pxb,id=bridge1,bus_nr=4 \
>>>> -device
>>>> e1000,netdev=netdev0,bus=bridge1,addr=2,romfile=,bootindex=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 "/address@hidden" 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. "/address@hidden".)
>>>>
>>>> Something has to be invented here to clue in both firmwares as to
>>>> the root bus number (here bus_nr=4), in a format that is
>>>> compliant
>>>> with the "OpenFirmware unit address" concept. (Note that
>>>> "/address@hidden" only gives away the slot number *on* the extra
>>>> root
>>>> bus, not the number of the root bus itself.) For example:
>>>>
>>>> /address@hidden/address@hidden/address@hidden/address@hidden
>>>>
>>>> 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
>>
>> address@hidden: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 “, . _ + - ”.
>> 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/QemuBootOrderLib/QemuBootOrderLib.c#L582
>>
>>
>> * Therefore, the only kind of /unit address/ that OVMF has faced,
>> exposed by QEMU, is "comma separated list of hexadecimal integers". OVMF
>> 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 me
>> revise my earlier recommendation, and ask for:
>>
>> /address@hidden/address@hidden/address@hidden/address@hidden
>> ^
>> 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
>>
>> /address@hidden
>>
>> (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:
>>
>> /address@hidden
>> /address@hidden
> 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.
>
> Thanks,
> Marcel
>
>>
>> Thanks
>> Laszlo
>>
>
- [Qemu-devel] [PATCH 4/4] i386/acpi-build: build_crs(): fetch BAR from PCI config space directly, (continued)
Re: [Qemu-devel] PXB fixes for QEMU, and extra root buses for OVMF, Marcel Apfelbaum, 2015/06/10