Indeed unlike Windows and Linux iPXE vmxnet3 driver makes additional assumptions regarding device functionality. I've fixed this and verified proper iPXE functionality (latest version). Will submit patch in a separate mail.
On Wed, Mar 27, 2013 at 6:56 PM, Dmitry Fleytman <[email protected]> wrote: > Hi Stefan, > > The issue is we never tested this device with iPXE, so according to > Murphy's law it cannot work :). > We'll take a look... > > Dmitry. > > > On Mon, Mar 25, 2013 at 2:26 PM, Stefan Hajnoczi <[email protected]>wrote: > >> Hi Dmitry, >> QEMU vmxnet3 produces the following warning with iPXE >> (77f64b11f764e721f4f8704b7b90317e52d85fc3): >> >> $ cd ~/ipxe/src >> $ make bin/vmxnet3.rom >> $ qemu-system-x86_64 -netdev user,id=netdev0 -device >> vmxnet3,netdev=netdev0,romfile=bin/vmxnet3.rom >> [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio >> extension. Task offloads will be emulated. >> [vmxnet3][WR][vmxnet3_get_command_status]: Received request for >> unknown command: cafe0002 >> >> The warning about virtio extensions is expected since I chose slirp >> networking. >> >> iPXE does not show the NIC ('ifstat' command). I guess the driver >> gave up during initialization: >> >> https://git.ipxe.org/ipxe.git/blob/HEAD:/src/drivers/net/vmxnet3.c#l613 >> >> Any ideas? >> >> Stefan >> >> PS: I discovered this when testing net patches for the pull request I >> just sent out. It's not a blocker, so vmxnet3 will finally be in >> qemu.git/master very soon! >> > >
