QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: BALATON Zoltan <balaton@eik.bme.hu>
To: qemu-devel@nongnu.org
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: [Qemu-devel] Machine specific option ROMs
Date: Mon, 19 Aug 2019 02:38:09 +0200 (CEST)
Message-ID: <alpine.BSF.2.21.9999.1908190208150.57965@zero.eik.bme.hu> (raw)


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.)


             reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19  0:38 BALATON Zoltan [this message]
2019-08-19  6:15 ` Gerd Hoffmann
2019-08-19 23:42   ` BALATON Zoltan
2019-08-20  6:25     ` Gerd Hoffmann
2019-08-20 10:46       ` BALATON Zoltan
2019-08-20 12:28         ` Gerd Hoffmann
2019-08-20 14:01           ` BALATON Zoltan

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.BSF.2.21.9999.1908190208150.57965@zero.eik.bme.hu \
    --to=balaton@eik.bme.hu \
    --cc=kraxel@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=qemu-devel@nongnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git