[Qemu-devel] Re: [PATCH v2] net: Fix hotplug with pci_add

[Juan Quintela <quintela@redhat.com>]

Markus Armbruster <armbru@redhat.com> wrote:
> Amit Shah <amit.shah@redhat.com> writes:
>
>> On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote:
>>> Amit Shah <amit.shah@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.