On Thu, Jun 21, 2018 at 7:30 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Thu, Jun 21, 2018 at 06:07:18PM -0700, Siwei Liu wrote: >> On Thu, Jun 21, 2018 at 11:14 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Wed, Jun 13, 2018 at 01:40:59PM +0800, Jason Wang wrote: >> >> >> >> >> >> On 2018年06月13日 12:24, Samudrala, Sridhar wrote: >> >> > On 6/12/2018 7:38 PM, Jason Wang wrote: >> >> > > >> >> > > >> >> > > On 2018年06月12日 19:54, Michael S. Tsirkin wrote: >> >> > > > On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: >> >> > > > > >> >> > > > > On 2018年06月05日 20:33, Michael S. Tsirkin wrote: >> >> > > > > > I don't think this is sufficient. >> >> > > > > > >> >> > > > > > If both primary and standby devices are present, a >> >> > > > > > legacy guest without >> >> > > > > > support for the feature might see two devices with same mac and >> >> > > > > > get >> >> > > > > > confused. >> >> > > > > > >> >> > > > > > I think that we should only make primary visible after >> >> > > > > > guest acked the >> >> > > > > > backup feature bit. >> >> > > > > I think we want exactly the reverse? E.g fail the >> >> > > > > negotiation when guest >> >> > > > > does not ack backup feature. >> >> > > > > >> >> > > > > Otherwise legacy guest won't even have the chance to see >> >> > > > > primary device in >> >> > > > > the guest. >> >> > > > That's by design. >> >> > > >> >> > > So management needs to know the capability of guest to set the >> >> > > backup feature. This looks a chicken or egg problem to me. >> >> > >> >> > I don't think so. If the tenant requests 'accelerated datapath feature', >> >> > the management >> >> > will set 'standby' feature bit on virtio-net interface and if the guest >> >> > virtio-net driver >> >> > supports this feature, then the tenant VM will get that capability via a >> >> > hot-plugged >> >> > primary device. >> >> >> >> Ok, I thought exactly the reverse because of the commit title is "enable >> >> virtio_net to act as a standby for a passthru device". But re-read the >> >> commit log content, I understand the case a little bit. Btw, VF is not >> >> necessarily faster than virtio-net, especially consider virtio-net may >> >> have >> >> a lot of queues. >> > >> > Don't do that then, right? >> >> I don't understand. Where did the standby feature come to imply the >> "accelerated datapath" thing? >> Isn't failover/standby a generic high >> availblity term, rather than marry it to the concept of device model >> specifics? Do we expect scsi to work exactly the same way with >> "accelerated datapath"? > > That's not what I said. > 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, as the originial problem is migrating vfio devices which is in match of QEMU's live migration model. Hyper-V has it's limitation to do 1-netdev should not impact how KVM/QEMU should be doing it. > 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 > failover isn't it though. > > -- > MST _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
