Thread (3 messages) 3 messages, 2 authors, 2018-06-22

Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2018-06-22 22:28:57

Possibly related (same subject, not in this thread)

On Fri, Jun 22, 2018 at 03:25:19PM -0700, Siwei Liu wrote:
On Fri, Jun 22, 2018 at 2:47 PM, Michael S. Tsirkin [off-list ref] wrote:
quoted
On Fri, Jun 22, 2018 at 12:43:26PM -0700, Siwei Liu wrote:
quoted
quoted
The semantics are that the primary is always used if present in
preference to standby.
OK. If this is the only semantics of what "standby" refers to in
general, that is fine.

I just don't want to limit the failover/standby semantics to the
device model specifics, the "accelerated datapath" thing or whatever.
I really don't know where the requirements of the "accelerated
datapath" came from,
It's a way to put it that matches what failover actually provides.
quoted
as the originial problem is migrating vfio
devices which is in match of QEMU's live migration model.
If you put it this way then it's natural to require that we have a
config with a working vfio device, and that we somehow add virtio for
duration of migration.
OK. That's the STANDBY feature sematics as I expect.
Maybe but that isn't what virtio or hyperv implement.
If someone tells you otherwise, they are mistaken IMHO.
Not something like "we have a working virtio, but we need an
accelerated datapath via VFIO when the VM is not migrating". The VFIO
is the what needs to be concerned with, not the virtio.
The way I view it, the STANDBY feature, although present in the virtio
device, is served as a communication channel for the paired VFIO
device, and the main purpose of its feature negotiation process has to
be around for migrating the corresponding VFIO. While it's possible to
re-use it as a side way to achieve "accelerated datapath".

There could be other alternatives for vfio migration though, which do
not need the virtio helper, so don't need to get a STANDBY virtio for
that VFIO device.
quoted
quoted
Hyper-V has
it's limitation to do 1-netdev should not impact how KVM/QEMU should
be doing it.
That's a linux thing and pretty orthogonal to host/guest interface.
I agree. So don't assume any device model specifics in the host/guest interface.
quoted
quoted
quoted
Jason said virtio net is sometimes preferable.
If that's the case don't make it a standby.

More advanced use-cases do exist and e.g. Alexander Duyck
suggested using a switch-dev.
The switchdev case would need a new feature bit, right?

-Siwei
I think it would need to be a completely new device.
So how it relates to virtio or failover?

Regards,
-Siwei
It might with time offer a super-set of the features.
quoted
quoted
quoted
failover isn't it though.

--
MST
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help