Amit Shah <amit.s...@redhat.com> writes: > On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote: >> Amit Shah <amit.s...@redhat.com> writes: >> >> > The correct model type wasn't getting added when hotplugging nics with >> > pci_add. >> > >> > Testcase: start VM with default nic type. In the qemu_monitor: >> > >> > (qemu) pci_add auto nic model=virtio >> > >> > This results in a nic hot-plug of the same nic type as the default. >> >> Works fine for me on master, fd1dc858370d9a9ac7ea2512812c3a152ee6484b. >> What am I doing wrong? > > Did you start with a virtio nic added? The 'default' here is the nic > type that's added as the first nic. Try this: start a VM with model > e1000 and use pci_add to add a nic type of virtio.
I do. Nevertheless, "pci_add auto nic model=e1000" adds an e1000. Also works if I start without a NIC. Ah, if I start with a -net nic, then pci_add breaks as described! Now my next question is *how* your patch fixes this. It's not at all obvious to me. >> > This was broken in 5294e2c774f120e10b44652ac143abda356f44eb >> > >> > Also changes the behaviour where no .init is defined for a >> > net_client_type. Previously, 0 was returned, which indicated the init >> > was successful and that 0 was the index into the nd_tables[] array. >> > Return -1, indicating unsuccessful init, in such a case. >> >> The only element of net_client_types[] without an init() method is type >> "none", index 0. So, doesn't this break -net none? And what does it >> fix? > > The net_client_types[] index isn't relevant here. -net none works fine, > no problem. Let me rephrase: Behavior changes for -net types without an init() method. The only one without an init() method is "none". Before, net_client_init() succeeded for it. Now it fails. What's the impact of that change? And why does it make sense?
