[Qemu-devel] Machine specific option ROMs

[Qemu-devel] Machine specific option ROMs

[BALATON Zoltan]

Hello,

I know about the possibility to set the option ROM of a PCIDevice with the 
romfile property (that we can set on command line or in a device's init 
method) but is there a way to set it depending on the machine that uses 
the device? If this is not currently possible what would be needed to 
allow this?

I'm asking because some cards may have different option ROMs on different 
platforms: e.g. gfx cards need different ROM on Mac than on PC due to 
using different firmware (and CPU arch). For Mac machines emulated by QEMU 
OpenBIOS now patches in a driver that it downloads via FW_CFG but it could 
use an FCode ROM (or the driver directly passed as the ROM image) instead 
which would be a simpler solution and more like how real hardware works. 
Also sam460ex firmware has a BIOS emulator for using PC option ROMs but 
that can't run QEMU vgabios binaries (as these are i386 real mode and it 
can only run x86 real mode) so we may need a way to specify a different 
ROM if the card is used in sam460ex.

So I'm looking for a way for board code to set romfile when the device is 
added to the board. Should the normal way of setting a property work for 
this or is that too late by then to change ROM of the device? (Also this 
may need to work together with the -vga option to ensure card has the 
right ROM on different machines even if added by -vga.)

Regards,
BALATON Zoltan

Re: [Qemu-devel] Machine specific option ROMs

[Gerd Hoffmann]

On Mon, Aug 19, 2019 at 02:38:09AM +0200, BALATON Zoltan wrote:
> Hello,
> 
> I know about the possibility to set the option ROM of a PCIDevice with the
> romfile property (that we can set on command line or in a device's init
> method) but is there a way to set it depending on the machine that uses the
> device? If this is not currently possible what would be needed to allow
> this?

Should work with compat properties.  That is a list of device, property
and value which a specific machine type should use.  Typically they are
used to make versioned machine types behave simliar to older qemu
versions (this is where the name comes from).  Using them to use
non-default properties on ppc platform should work too.

For example in qemu 1.5 the nic roms got EFI support and there is a
compat property which switches the pc-i440fx-1.4 (and older) machine
types to the non-efi versions.  Grep for pxe-e1000.rom to find the code.

HTH,
  Gerd

Re: [Qemu-devel] Machine specific option ROMs

[BALATON Zoltan]

On Mon, 19 Aug 2019, Gerd Hoffmann wrote:
> On Mon, Aug 19, 2019 at 02:38:09AM +0200, BALATON Zoltan wrote:
>> I know about the possibility to set the option ROM of a PCIDevice with the
>> romfile property (that we can set on command line or in a device's init
>> method) but is there a way to set it depending on the machine that uses the
>> device? If this is not currently possible what would be needed to allow
>> this?
>
> Should work with compat properties.  That is a list of device, property
> and value which a specific machine type should use.  Typically they are
> used to make versioned machine types behave simliar to older qemu
> versions (this is where the name comes from).  Using them to use
> non-default properties on ppc platform should work too.
>
> For example in qemu 1.5 the nic roms got EFI support and there is a
> compat property which switches the pc-i440fx-1.4 (and older) machine
> types to the non-efi versions.  Grep for pxe-e1000.rom to find the code.

OK thanks, looks like something like this works:

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index c5bbcc7433..8ee937e3ce 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -569,6 +572,10 @@ static int core99_kvm_type(MachineState *machine, const char *arg)
     return 2;
 }

+static GlobalProperty compat[] = {
+    { "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+
 static void core99_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
@@ -587,6 +594,7 @@ static void core99_machine_class_init(ObjectClass *oc, void *data)
     mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
 #endif
     mc->ignore_boot_device_suffixes = true;
+    compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
     fwc->get_dev_path = core99_fw_dev_path;
 }



Mark, do you think this could replace the current way of passing this 
driver via fw_cfg and would you accept patches to OpenBIOS to revert the 
ndrv patching to replace that with this solution? (The vga_config_cb 
already adds the driver from the ROM when set as above so no further hacks 
are necessary. If we want we can keep the vga-ndrv? option to control this 
adding NDRV from ROM after the current use of this setting is no longer 
needed.) I think this would allow some simplification and also avoids 
patching ati-vga with this driver without needing to add vga-ndrv?=false 
manually. (In the future this same way can also be used to pass proper 
FCode ROMs to OpenBIOS.)

Regards,
BALATON Zoltan

Re: [Qemu-devel] Machine specific option ROMs

[Gerd Hoffmann]

  Hi,

> > For example in qemu 1.5 the nic roms got EFI support and there is a
> > compat property which switches the pc-i440fx-1.4 (and older) machine
> > types to the non-efi versions.  Grep for pxe-e1000.rom to find the code.

Note that roms with a pci firmware standard header[1] can be chained
together, then placed in the pci rom bar.  This is how the efi-*.rom
files are created, they are three-in-one images (bios, efi ia32, efi
x64).

   # file pc-bios/qemu_vga.ndrv
   pc-bios/qemu_vga.ndrv: header for PowerPC PEF executable

Hmm, so that is probably not going to work.

> +static GlobalProperty compat[] = {
> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
> +};

> +    compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));

I wouldn't name the variable compat (in this specific case it's not for
backward compatibility), but yes, this is the idea.

> manually. (In the future this same way can also be used to pass proper 
> FCode ROMs to OpenBIOS.)

The image type (pci rom header) can be:

   Type      Description
   0         Intel x86, PC-AT compatible
   1         Open Firmware standard for PCI
   2         Hewlett-Packard PA RISC
   3         Extensible Firmware Interface (EFI) 
   4-FF      Reserved

So having a single pci rom image with both classic vgabios (type 0) and
open firmware fcode (type 1) should be possible.

cheers,
  Gerd

[1] http://read.pudn.com/downloads211/doc/comm/994029/pcifw_r3_0_updated.pdf, section 5.1

Re: [Qemu-devel] Machine specific option ROMs

[BALATON Zoltan]

On Tue, 20 Aug 2019, Gerd Hoffmann wrote:
>>> For example in qemu 1.5 the nic roms got EFI support and there is a
>>> compat property which switches the pc-i440fx-1.4 (and older) machine
>>> types to the non-efi versions.  Grep for pxe-e1000.rom to find the code.
>
> Note that roms with a pci firmware standard header[1] can be chained
> together, then placed in the pci rom bar.  This is how the efi-*.rom
> files are created, they are three-in-one images (bios, efi ia32, efi
> x64).
>
>   # file pc-bios/qemu_vga.ndrv
>   pc-bios/qemu_vga.ndrv: header for PowerPC PEF executable
>
> Hmm, so that is probably not going to work.
>
>> +static GlobalProperty compat[] = {
>> +    { "VGA", "romfile", NDRV_VGA_FILENAME },
>> +};
>
>> +    compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
>
> I wouldn't name the variable compat (in this specific case it's not for
> backward compatibility), but yes, this is the idea.
>
>> manually. (In the future this same way can also be used to pass proper
>> FCode ROMs to OpenBIOS.)
>
> The image type (pci rom header) can be:
>
>   Type      Description
>   0         Intel x86, PC-AT compatible
>   1         Open Firmware standard for PCI
>   2         Hewlett-Packard PA RISC
>   3         Extensible Firmware Interface (EFI)
>   4-FF      Reserved
>
> So having a single pci rom image with both classic vgabios (type 0) and
> open firmware fcode (type 1) should be possible.
>
> cheers,
>  Gerd
>
> [1] http://read.pudn.com/downloads211/doc/comm/994029/pcifw_r3_0_updated.pdf, section 5.1

Thanks for investigating it. However there are at least two problems with 
that idea:

1. OpenBIOS does not yet understand standard PCI ROM headers, it can only 
handle NDRV and PEF ROMs yet so first support for that (and FCode ROMs) 
should be added to OpenBIOS.

2. Building rom images from different sources (in this case your vgabios 
and QemuMacDrivers for the NDRV) might not be straightforward (maybe some 
clever make rules would take care of these without too much hassle but I'm 
not sure, this would mean rebuilding binary if any of the two sources 
change).

Plus I don't know if other firmwares such as sam460ex U-Boot can handle 
such multiplatform ROMs, especially because it can use x86 ROM just not 
the QEMU vgabios due to not emulating i386 specific opcodes that gcc puts 
in real mode code so it needs something compiled with bcc such as 
Plex86/Bochs VGABios so then we can't put those in one binary because we 
had two x86 images in it. Therefore I think setting this based on machine 
like above is probably the easiest way for now.

I'll wait for Mark's comments before going further with this.

Regards,
BALATON Zoltan

Re: [Qemu-devel] Machine specific option ROMs

[Gerd Hoffmann]

  Hi,

> Plus I don't know if other firmwares such as sam460ex U-Boot can handle such
> multiplatform ROMs, especially because it can use x86 ROM

Yes, how the guest treats those roms is another issue.  bios/efi combo
roms on x86 are not that uncommon.  But I'm not sure how widespread
bios/openfirmare combo roms are used (have been used) in practice.  If
guests can't deal with it (and try to run a x86 emulator on the bios
image instead) it might not be the best plan to go that route.

> just not the QEMU
> vgabios due to not emulating i386 specific opcodes that gcc puts in real
> mode code

What does sam460ex use?  Some x86emu fork?  If so upgrading might help.
Xorg uses x86emu too and older versions have problems with the
gcc-generated real mode code too.

cheers,
  Gerd

Re: [Qemu-devel] Machine specific option ROMs

[BALATON Zoltan]

On Tue, 20 Aug 2019, Gerd Hoffmann wrote:
> Yes, how the guest treats those roms is another issue.  bios/efi combo
> roms on x86 are not that uncommon.  But I'm not sure how widespread
> bios/openfirmare combo roms are used (have been used) in practice.  If

I haven't heard about such BIOS/OF ROMs (which does not mean much as I 
don't know much about this) but I think it's probably not widespread if 
used at all. I think ROM size on cards were limited for cost reasons so 
instead of trying to fit more images in one limited space vendors usually 
produced separate versions for x86 and Macs with different ROM image. At 
least there's a lot of info on how to convert PC cards to Mac by 
reflashing ROM which would not be needed if these had support in ROM.

> guests can't deal with it (and try to run a x86 emulator on the bios
> image instead) it might not be the best plan to go that route.

Some clients do have BIOS emulation while also can use OF ROM like 
pegasos2's SmartFirmware but I don't know how that would handle 
multiplatform ROMs so it's better go the simpler way which seems to have 
less problems and just set the ROM the clients are most likely to support 
by machine emulation. Multiplatform ROMs are an interesting possibility 
but looks like more trouble in practice than it could bring.

>> just not the QEMU
>> vgabios due to not emulating i386 specific opcodes that gcc puts in real
>> mode code
>
> What does sam460ex use?  Some x86emu fork?  If so upgrading might help.
> Xorg uses x86emu too and older versions have problems with the
> gcc-generated real mode code too.

It has x86emu in roms/u-boot-sam460ex/board/ACube/bios_emulator and is 
likely old version because this is from 2010/2011. (I think I've also 
tried enabling the option in vgabios for x86emu fixups before but that did 
not help or maybe that was with pegasos2 which does not even have firmware 
sources to update, yet it's useful to test with original firmware so I'd 
like to get that working eventually.) For sam460ex there's a newer, 
updated firmware version from 2015 the sources of which are available from 
the vendor here:

http://acube-systems.biz/index.php?page=hardware&pid=5

but I don't know if that has newer x86emu and haven't tested if it works 
with QEMU. I also had to fix bugs in the previous version to compile and 
work so unless there's a good reason I don't want to spend time trying to 
update sam460ex firmware. The current version works enough to boot OSes 
and I don't want to start maintaining and fixing a commercial vendor's 
firmware. They can support it if they want.

Regards,
BALATON Zoltan