qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Stefan Weil <weil@mail.berlios.de>
Cc: Markus Armbruster <armbru@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI device id in	PCI ROM
Date: Mon, 18 Oct 2010 13:54:26 +0200	[thread overview]
Message-ID: <4CBC3572.6000908@redhat.com> (raw)
In-Reply-To: <4CBC2C7A.4000803@mail.berlios.de>

   Hi,

> As far as I know there is no well-defined checksum offset.
> The checksum is simply set by modifying any byte (which
> normally should be unused).
>
> Etherboot has some unused bytes at the beginning of rom data
> and always uses the same offset 6.

Ah, so you don't actually update the checksum but change some unused 
byte to make the checksum stay the same, right?

> For other roms which also don't use the byte at offset 6, this approach
> will work, too. If they store code or vital data at that location,
> we destroy that data, so it won't work.
>
> The VGA bios roms have a sequence of several bytes of zero
> starting at offset 6, so maybe this data is not important and
> we may change the byte at offset 6, but that should be checked
> before using this mechanism.

 From vgabios:

     .org 0

     vgabios_start:
     .byte  0x55, 0xaa	/* BIOS signature */
     .byte  0x40		/* BIOS extension length */

     vgabios_entry_point:
           jmp vgabios_init_func

 From seabios:

     struct rom_header {
         u16 signature;
         u8 size;
         u8 initVector[4];
         u8 reserved[17];
         u16 pcioffset;
         u16 pnpoffset;
     } PACKED;

Hmm.  So offset 6 is the last byte of initVector.  If (and only if) you 
happen to know that the jump instruction takes 3 bytes only it is save 
to modify the unused 4th byte.  Seems to be true for both vgabios and 
etherboot/gPXE.  We can't assume this in general, although it is quite 
likely given that there hardly would be anything but a 16bit jump.

> As long as the driver specifies the romfile name,
> we get an implicitly defined behaviour: either the
> rom matches and nothing special is done, or it doesn't
> and the id(s) will be fixed.

> So neither flag nor opt-in seems to be needed.

When following this argumentation the vendor id sanity check shouldn't 
be there in the first place ;)

Note that romfile is a pci bus property, so it isn't fully under the 
drivers control because it can be overridden from the command line for 
every pci device.

cheers,
   Gerd

  reply	other threads:[~2010-10-18 11:54 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-12 12:41 [Qemu-devel] Where's gpxe-eepro100-80862449.rom ? Markus Armbruster
2010-10-12 16:18 ` [Qemu-devel] " Stefan Weil
2010-10-13  7:13   ` Markus Armbruster
2010-10-15 20:51     ` [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI device id in PCI ROM Stefan Weil
2010-10-15 21:05       ` Anthony Liguori
2010-10-18 10:09         ` Gerd Hoffmann
2010-10-18 18:39           ` Anthony Liguori
2010-10-21 10:09             ` [SeaBIOS] " Avi Kivity
2010-10-21 13:14               ` Anthony Liguori
2010-10-21 15:34                 ` Avi Kivity
2010-10-18 10:04       ` Gerd Hoffmann
2010-10-18 11:16         ` Stefan Weil
2010-10-18 11:54           ` Gerd Hoffmann [this message]
2010-10-18 13:16             ` Stefan Weil
2010-10-18 13:30               ` Gerd Hoffmann
2010-10-18 15:50                 ` Gerd Hoffmann
2010-10-18 17:54                   ` Stefan Weil
2010-10-18 17:55                   ` [Qemu-devel] [PATCH 1/2] pci: Automatically patch PCI vendor id and " Stefan Weil
2010-10-18 17:58                     ` [Qemu-devel] " Michael S. Tsirkin
2010-10-18 18:42                       ` Anthony Liguori
2010-10-18 19:03                         ` Michael S. Tsirkin
2010-10-18 19:36                           ` Stefan Weil
2010-10-18 19:59                             ` Anthony Liguori
2010-10-19  6:40                             ` Gerd Hoffmann
2010-10-18 19:56                           ` Anthony Liguori
2010-10-18 18:44                     ` [Qemu-devel] " Anthony Liguori
2010-10-18 18:53                       ` Anthony Liguori
2010-10-18 19:11                         ` Stefan Weil
2010-10-19  8:37                           ` Michael S. Tsirkin
2010-10-19 21:15                             ` Stefan Weil
2010-10-19 21:22                               ` Anthony Liguori
2010-10-19 21:25                                 ` Michael S. Tsirkin
2010-10-19 21:08                         ` Stefan Weil
2010-10-20  7:19                           ` [Qemu-devel] " Gerd Hoffmann
2010-10-20 20:30                             ` Stefan Weil
2010-11-22  6:29                           ` Michael S. Tsirkin
2010-10-15 20:51     ` [Qemu-devel] [PATCH 2/2] eepro100: Use a single rom file for all i825xx devices Stefan Weil
2010-11-22  6:29       ` [Qemu-devel] " Michael S. Tsirkin
2010-10-15 21:03     ` [Qemu-devel] Re: Where's gpxe-eepro100-80862449.rom ? Stefan Weil
2010-10-25 12:11       ` Markus Armbruster
2010-10-25 16:23         ` Stefan Weil
2010-10-25 16:54           ` Michael S. Tsirkin
2010-11-15 17:06             ` Stefan Weil

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=4CBC3572.6000908@redhat.com \
    --to=kraxel@redhat.com \
    --cc=armbru@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=weil@mail.berlios.de \
    /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).