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 <m...@redhat.com> wrote: > > On Fri, Jun 22, 2018 at 12:43:26PM -0700, Siwei Liu wrote: > >> > 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. > > > >> 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. > > > > >> 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. > > > > >> > 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. > > > >> > failover isn't it though. > >> > > >> > -- > >> > MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
