qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH v3] Do not try loading option ROM for hotplug PC


From: Gerd Hoffmann
Subject: [Qemu-devel] Re: [PATCH v3] Do not try loading option ROM for hotplug PCI device in pc-0.11 compat mode
Date: Mon, 30 Aug 2010 15:57:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100805 Red Hat/3.1.2-2.el6 Thunderbird/3.1.2

On 08/30/10 15:45, Anthony Liguori wrote:
On 08/30/2010 08:11 AM, Jes Sorensen wrote:
On 08/30/10 15:00, Anthony Liguori wrote:
On 08/30/2010 03:16 AM, address@hidden wrote:
From: Jes Sorensen<address@hidden>

pc-0.11 and older uses fw_cfg to provide option ROMs. As fw_cfg is
setup
at init time, it is not possible to load an option ROM for a hotplug
device when running in compat mode.

v2: Alex Williamson pointed out that one can get to qdev directly from
pci_dev, so no need to pass it down.

v3: Braces

What's the specific bug? The devices themselves have a check for
hotplug which inhibits rom addition during hotplug so either there's a
device missing this check or if we're going to go this route, we ought
to remove those checks in the other devices.
If you run in -M pc-0.11 or older option ROMs are provided via fw_cfg,
which means QEMU is unable to load it after boot time if you try to
hot-plug a new network device via the monitor. Instead it decides to
exit with an error.

Which network device?

Take a look at ne2k.c's rom loading. It's got logic for rom loading with
hotplug but e1000 and rtl8139 don't. Maybe it's because ne2k also
supports an ISA mode?

I think I just forgot to convert ne2k over to using .romfile instead.

Just skipping fw_cfg-based rom loading looks sane to me. After all it is just for pc-0.11 compatibility. And it is even bug compatible: hot-plug nic + reboot + pxe-boot from the hot-plugged nic didn't work in 0.11 too ;)

cheers,
  Gerd




reply via email to

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