qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 09/11] qdev: Avoid QemuOpts in QMP device_add


From: Laurent Vivier
Subject: Re: [PATCH 09/11] qdev: Avoid QemuOpts in QMP device_add
Date: Wed, 6 Oct 2021 11:20:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0

On 06/10/2021 10:21, Juan Quintela wrote:
Kevin Wolf <kwolf@redhat.com> wrote:
Am 05.10.2021 um 17:52 hat Damien Hedde geschrieben:

Hi

Usage
-----

The primary device can be hotplugged or be part of the startup
configuration

   -device virtio-net-pci,netdev=hostnet1,id=net1,
           mac=52:54:00:6f:55:cc,bus=root2,failover=on

With the parameter failover=on the VIRTIO_NET_F_STANDBY feature
will be enabled.

-device vfio-pci,host=5e:00.2,id=hostdev0,bus=root1,
         failover_pair_id=net1

failover_pair_id references the id of the virtio-net standby device.
This is only for pairing the devices within QEMU. The guest kernel
module net_failover will match devices with identical MAC addresses.

Hotplug
-------

Both primary and standby device can be hotplugged via the QEMU
monitor.  Note that if the virtio-net device is plugged first a
warning will be issued that it couldn't find the primary device.

So maybe this whole primary device lookup can happen during the -device CLI
option creation loop. And we can indeed have un-created devices still in the
list ?

Yes, that's the only case for which I could imagine for an inconsistency
between the qdev tree and QemuOpts, but failover_add_primary() is only
called after feature negotiation with the guest driver, so we can be
sure that the -device loop has completed long ago.

And even if it hadn't completed yet, the paragraph also says that even
hotplugging the device later is supported, so creating devices in the
wrong order should still succeed.

I hope that some of the people I added to CC have some more hints.

Failover is ... interesting.

You have two devices: primary and seconday.
seconday is virtio-net, primary can be vfio and some other emulated
devices.

In the command line, devices can appear on any order, primary then
secondary, secondary then primary, or only one of them.
You can add (any of them) later in the toplevel.

And now, what all this mess is about.  We only enable the primary if the
guest knows about failover.  Otherwise we use only the virtio device
(*).  The important bit here is that we need to wait until the guest is
booted, and the virtio-net driver is loaded, and then it tells us if it
understands failover (or not).  At that point we decide if we want to
"really" create the primary.

I know that it abuses device_add() as much as it can be, but I can't see
any better way to handle it.  We need to be able to "create" a device
without showing it to the guest.  And later, when we create a different
device, and depending of driver support on the guest, we "finish" the
creation of the primary device.

Any good idea?

I don't know if it can help the discussion, but I'm reformatting the failover code to move all the PCI stuff to pci files.

And there is a lot of inconsistencies regarding the device_add and --device option so I've been in the end to add a list of of hidden devices rather than relying on the command line.

See PATCH 8 of series "[RFC PATCH v2 0/8] virtio-net failover cleanup and new 
features"

https://patchew.org/QEMU/20210820142002.152994-1-lvivier@redhat.com/

Thanks,
Laurent




reply via email to

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