From: Laszlo Ersek <lersek@redhat.com>
To: Marcel Apfelbaum <marcel@redhat.com>, qemu-devel@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 6/6] hw/pci-bridge: set explicit OFW unit address for TYPE_PXB_HOST
Date: Thu, 11 Jun 2015 11:50:58 +0200 [thread overview]
Message-ID: <55795A02.9080109@redhat.com> (raw)
In-Reply-To: <557951A5.5060201@redhat.com>
On 06/11/15 11:15, Marcel Apfelbaum wrote:
> On 06/11/2015 03:38 AM, 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 change the fw_name device class member of TYPE_PXB_HOST
>> from "pci" to "pci-root", and set each instance's explicit OFW unit
>> address to the PXB bus number. The same command line fragment results in
>> the following OpenFirmware device path in the "bootorder" fw_cfg file:
>>
>> /pci-root@4/pci-bridge@0/ethernet@2/ethernet-phy@0
> Clean
>
>>
>> The original, initial "/pci" fragment has been replaced with
>> "/pci-root@4", which (a) looks better, (b) provides all the necessary
>> information.
>>
>> Cc: Markus Armbruster <armbru@redhat.com>
>> Cc: Marcel Apfelbaum <marcel@redhat.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> v3:
>> - using new sysbus device property, not inserting additional bus
>>
>> hw/pci-bridge/pci_expander_bridge.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/pci-bridge/pci_expander_bridge.c
>> b/hw/pci-bridge/pci_expander_bridge.c
>> index c7a085d..d468670 100644
>> --- a/hw/pci-bridge/pci_expander_bridge.c
>> +++ b/hw/pci-bridge/pci_expander_bridge.c
>> @@ -93,7 +93,7 @@ static void pxb_host_class_init(ObjectClass *class,
>> void *data)
>> DeviceClass *dc = DEVICE_CLASS(class);
>> PCIHostBridgeClass *hc = PCI_HOST_BRIDGE_CLASS(class);
>>
>> - dc->fw_name = "pci";
>> + dc->fw_name = "pci-root";
>> hc->root_bus_path = pxb_host_root_bus_path;
>> }
>>
>> @@ -152,6 +152,7 @@ static int pxb_dev_initfn(PCIDevice *dev)
>> {
>> PXBDev *pxb = PXB_DEV(dev);
>> DeviceState *ds, *bds;
>> + char *bus_nr_str;
>> PCIBus *bus;
>> const char *dev_name = NULL;
>>
>> @@ -166,6 +167,10 @@ static int pxb_dev_initfn(PCIDevice *dev)
>> }
>>
>> ds = qdev_create(NULL, TYPE_PXB_HOST);
>> + bus_nr_str = g_strdup_printf("%x", pxb->bus_nr);
>> + qdev_prop_set_string(ds, "explicit_ofw_unit_address", bus_nr_str);
>> + g_free(bus_nr_str);
>
> This is the best approach yet.
> I think it will not affect migration, because on the target site
> it will have the same bus number, so the property doesn't need to be
> passed.
Yes, I thought the same.
Migration should carry guest-alterable state. If, in some device,
"explicit_ofw_unit_address" will ever be changed due to guest actions
(as opposed to deriving it from a constant on the command line, which
management would sync anyway), then that specific device will have to
migrate the underlying state as it sees fit, and update the property in
a post load callback.
>
> Is my time to see how it will work on Seabios.
> Thanks a lot for your help!!
>
> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Thanks! I hope to hear back from Michael and Markus as well. Until then,
this should suffice to work on the firmware(s).
Laszlo
>> +
>> bus = pci_bus_new(ds, "pxb-internal", NULL, NULL, 0, TYPE_PXB_BUS);
>>
>> bus->parent_dev = dev;
>>
>
next prev parent reply other threads:[~2015-06-11 9:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 0:37 [Qemu-devel] [PATCH v3 0/6] PXB tweaks and fixes Laszlo Ersek
2015-06-11 0:37 ` [Qemu-devel] [PATCH v3 1/6] i386/acpi-build: more traditional _UID and _HID for PXB root buses Laszlo Ersek
2015-06-11 0:37 ` [Qemu-devel] [PATCH v3 2/6] i386/acpi-build: fix PXB workarounds for unsupported BIOSes Laszlo Ersek
2015-06-11 0:38 ` [Qemu-devel] [PATCH v3 3/6] hw/pci-bridge: create interrupt-less, hotplug-less bridge for PXB Laszlo Ersek
2015-06-11 0:38 ` [Qemu-devel] [PATCH v3 4/6] hw/core: rebase sysbus_get_fw_dev_path() to g_strdup_printf() Laszlo Ersek
2015-06-11 9:08 ` Marcel Apfelbaum
2015-06-11 0:38 ` [Qemu-devel] [PATCH v3 5/6] hw/core: explicit OFW unit address property for SysBusDevice Laszlo Ersek
2015-06-11 9:12 ` Marcel Apfelbaum
2015-06-11 0:38 ` [Qemu-devel] [PATCH v3 6/6] hw/pci-bridge: set explicit OFW unit address for TYPE_PXB_HOST Laszlo Ersek
2015-06-11 9:15 ` Marcel Apfelbaum
2015-06-11 9:50 ` Laszlo Ersek [this message]
2015-06-11 10:21 ` Marcel Apfelbaum
2015-06-11 10:26 ` Laszlo Ersek
2015-06-11 10:29 ` Marcel Apfelbaum
2015-06-11 10:45 ` Laszlo Ersek
2015-06-11 10:55 ` Marcel Apfelbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55795A02.9080109@redhat.com \
--to=lersek@redhat.com \
--cc=armbru@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).