Markus Armbruster <arm...@redhat.com> wrote:
> 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.
Far away form the patch file. Look at:
hw/pci-hotplug.c
static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
const char *devaddr,
const char *opts_str)
{
.....
ret = net_client_init(mon, opts, 0);
.....
return pci_nic_init(&nd_table[ret], "rtl8139", devaddr);
}
You can see that accessing nd_table with value 1 as before was wrong.
BTW, once here, didn't default nic should be e1000? not rtl8139?
>>> > 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?
Here, I don't know.
Later, Juan.
