qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI vendor id and


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI vendor id and device id in PCI ROM
Date: Mon, 18 Oct 2010 21:11:55 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100913 Iceowl/1.0b1 Icedove/3.0.7

Am 18.10.2010 20:53, schrieb Anthony Liguori:
On 10/18/2010 01:44 PM, Anthony Liguori wrote:
On 10/18/2010 12:55 PM, Stefan Weil wrote:
PCI devices with different vendor or device ids sometimes share
the same rom code. Only the ids and the checksum
differs in a boot rom for such devices.

The i825xx ethernet controller family is a typical example
which is implemented in hw/eepro100.c. It uses at least
3 different device ids, so normally 3 boot roms would be needed.

By automatically patching vendor id and device id (and the checksum)
in qemu, all emulated family members can share the same boot rom.

VGA bios roms are another example with different vendor and device ids.

v2:

* Patch also the vendor id (and remove the sanity check for vendor id).

Cc: Gerd Hoffmann<address@hidden>
Cc: Markus Armbruster<address@hidden>
Cc: Michael S. Tsirkin<address@hidden>
Signed-off-by: Stefan Weil<address@hidden>

I get very nervous about patching a ROM. Who's to say that the ROM doesn't somehow depend on the contents of its header? Maybe it has an internal CRC built into it or something like that.

As part of PMM, ROMs typically reduce their size by decompressing and removing code or something of that nature and then rewrite themselves in scratch RAM. The BIOS then copies the resulting ROM (using the ROM size in the base header as an indication of how much to copy) into the option ROM space.

So the likelihood of depending on the contents of the header seems non-trivial to me.

Regards,

Anthony Liguori

[snip]

Etherboot uses compressed code and always fixes the checksum by modifying
the byte at relative address 6, so for etherboot there is no problem.
The etherboot distribution even includes a perl script which can be used
to patch vendor/device ids. I thought about using that script in QEMU's
make but then decided against this alternate solution.

VGA bios seems to work, too (practical test still is missing).

What could happen for other kinds of roms? Either there is nothing
to patch (the 99 % standard case), or they work, or they don't work.
QEMU must only make sure that patching of the supported roms
with supported devices work.

Regards,

Stefan Weil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]