From: Gerd Hoffmann <kraxel@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH v2 5/5] ne2k_isa: add property for option rom loading.
Date: Wed, 07 Oct 2009 16:00:25 +0200 [thread overview]
Message-ID: <4ACC9EF9.1010201@redhat.com> (raw)
In-Reply-To: <4ACC9765.3030300@codemonkey.ws>
On 10/07/09 15:28, Anthony Liguori wrote:
> Having a pxe flag is somewhat odd. Real network devices always have roms
> and they always get loaded. They register themselves as BEV devices and
> the normal boot selection is used to determine whether a particular NIC
> gets network booted or not.
>
> Our roms do expose themselves as BEV roms so there's really no harm in
> loading an option rom while booting from disk.
Wrong. Loading a pxe rom makes qemu trying to boot from it, even with
-boot c (using the roms shipped in pc-bios/).
Maybe SeaBIOS has better BEV support and handles things differently, so
we could load them unconditionally once we made the switch.
> Any PCI device can have a rom and it probably should be a generic
> property of any PCI device. There's really nothing specific about
> network adapters.
It's pc-specific though, so when we go the route of loading roms
unconditionally we need to wrap that into a machine-specific helper
function so it happes on TARGET_I386 only.
>> When making the filename configurable it should be a separate property
>> like "rom-name" or simliar. I would suggest to NOT implement it unless
>> users actually ask for it ;)
>
> Quite a few users today replace the standard etherboot roms with gPXE roms.
Usually with the same file names though, so a simple '-boot n' continues
to work.
cheers,
Gerd
next prev parent reply other threads:[~2009-10-07 14:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-07 12:36 [Qemu-devel] [RfC PATCH v2 0/5] qdev-ify network cards Gerd Hoffmann
2009-10-07 12:36 ` [Qemu-devel] [RFC PATCH v2 1/5] net: macaddr tweaks Gerd Hoffmann
2009-10-07 13:05 ` Anthony Liguori
2009-10-07 13:14 ` Gerd Hoffmann
2009-10-07 13:23 ` Anthony Liguori
2009-10-07 12:36 ` [Qemu-devel] [RFC PATCH v2 2/5] qdev: mac addr property fixups Gerd Hoffmann
2009-10-07 12:36 ` [Qemu-devel] [RFC PATCH v2 3/5] ne2k: work without vlan Gerd Hoffmann
2009-10-07 13:06 ` Anthony Liguori
2009-10-07 13:15 ` Gerd Hoffmann
2009-10-07 12:36 ` [Qemu-devel] [RFC PATCH v2 4/5] ne2k_isa: qdev-ify Gerd Hoffmann
2009-10-07 13:50 ` Mark McLoughlin
2009-10-07 14:07 ` Gerd Hoffmann
2009-10-07 12:36 ` [Qemu-devel] [RFC PATCH v2 5/5] ne2k_isa: add property for option rom loading Gerd Hoffmann
2009-10-07 13:08 ` Anthony Liguori
2009-10-07 13:21 ` Gerd Hoffmann
2009-10-07 13:28 ` Anthony Liguori
2009-10-07 14:00 ` Gerd Hoffmann [this message]
2009-10-07 14:17 ` Anthony Liguori
2009-10-07 14:27 ` Gerd Hoffmann
2009-10-07 18:34 ` Anthony Liguori
2009-10-12 10:13 ` Gerd Hoffmann
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=4ACC9EF9.1010201@redhat.com \
--to=kraxel@redhat.com \
--cc=anthony@codemonkey.ws \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.