Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
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 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
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Fri, Jun 22, 2018 at 2:47 PM, Michael S. Tsirkin 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. 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 > >> > 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
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
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. > 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. > > 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. > > 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
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Thu, Jun 21, 2018 at 7:30 PM, Michael S. Tsirkin 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 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 - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
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 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. 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. 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
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Thu, Jun 21, 2018 at 11:14 AM, Michael S. Tsirkin 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"? -Siwei > >> > >> > >> > > >> > > > >> > > > > > And on reset or when backup is cleared in some other way, unplug >> > > > > > the >> > > > > > primary. >> > > > > What if guest does not support hotplug? >> > > > It shouldn't ack the backup feature then and it's a good point. >> > > > We should both document this and check kernel config has >> > > > hotplug support. Sridhar could you take a look pls? >> > > > >> > > > > > Something like the below will do the job: >> > > > > > >> > > > > > Primary device is added with a special "primary-failover" flag. >> > > > > > A virtual machine is then initialized with just a standby virtio >> > > > > > device. Primary is not yet added. >> > > > > A question is how to do the matching? Qemu knows nothing about e.g >> > > > > mac >> > > > > address of a pass-through device I believe? >> > > > Supply a flag to the VFIO when it's added, this way QEMU will know. >> > > > >> > > > > > Later QEMU detects that guest driver device set DRIVER_OK. >> > > > > > It then exposes the primary device to the guest, and triggers >> > > > > > a device addition event (hot-plug event) for it. >> > > > > Do you mean we won't have primary device in the initial qemu cli? >> > > > No, that's not what I mean. >> > > > >> > > > I mean management will supply a flag to VFIO and then >> > > > >> > > > >> > > > - VFIO defers exposing >> > > > primary to guest until guest acks the feature bit. >> > > > - When we see guest ack, initiate hotplug. >> > > > - On reboot, hide it again. >> > > > - On reset without reboot, request hot-unplug and on eject hide >> > > > it again. >> > > >> > > This sounds much like a kind of bonding in qemu. >> > > >> > > > >> > > > > > If QEMU detects guest driver removal, it initiates a >> > > > > > hot-unplug sequence >> > > > > > to remove the primary driver. In particular, if QEMU detects guest >> > > > > > re-initialization (e.g. by detecting guest reset) it >> > > > > > immediately removes >> > > > > > the primary device. >> > > > > I believe guest failover module should handle this gracefully? >> > > > It can't control enumeration order, if primary is enumerated before >> > > > standby then guest will load its driver and it's too late >> > > > when failover driver is loaded. >> > > >> > > Well, even if we can delay the visibility of primary until >> > > DRIVER_OK, there still be a race I think? And it looks to me it's >> > > still a bug of guest: >> > > >> > > E.g primary could be probed before failover_register() in guest. >> > > Then we will miss the enslaving of primary forever. >> > >> > That is not an issue. Even if the primary is probed before failover >> > driver, it will >> > enslave the primary via the call to failover_existing_slave_register() >> > as
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Tue, Jun 12, 2018 at 4:47 AM, Michael S. Tsirkin wrote: > On Tue, Jun 05, 2018 at 03:09:26PM -0700, Siwei Liu wrote: >> The thing is cloud service provider might prefer sticking to the same >> level of service agreement (SLA) of keeping VF over migration, > > That requirement is trivially satisfied by just a single VF :) If your > SLA does not require live migration, you should do just that. The requirement is enable live migration by default without getting user too much attention. Migration should be attempted if guest is live migratable. If not, present a single VF to legacy guest. You seem to think it's not a valid use case? Or impossible to do so? What if I have something in mind that can support my theory as well? -Siwei > > -- > MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Tue, Jun 05, 2018 at 03:09:26PM -0700, Siwei Liu wrote: > The thing is cloud service provider might prefer sticking to the same > level of service agreement (SLA) of keeping VF over migration, That requirement is trivially satisfied by just a single VF :) If your SLA does not require live migration, you should do just that. -- MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Tue, Jun 5, 2018 at 2:32 PM, Michael S. Tsirkin wrote: > On Tue, Jun 05, 2018 at 02:16:44PM -0700, Siwei Liu wrote: >> Good to see this discussion going. I share the same feeling that the >> decision of plugging the primary (passthrough) should only be made >> until guest driver acknowledges DRIVER_OK and _F_STANDBY. >> Architecturally this intelligence should be baken to QEMU itself >> rather than moving up to management stack, such as libvirt. >> >> A few questions in line below. >> >> On Tue, Jun 5, 2018 at 5:33 AM, 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. >> > >> > And on reset or when backup is cleared in some other way, unplug the >> > primary. >> > >> > Something like the below will do the job: >> > >> > Primary device is added with a special "primary-failover" flag. >> >> I wonder if you envision this flag as a user interface or some >> internal attribute/property to QEMU device? >> >> Since QEMU needs to associate this particular primary-failover device >> with a virtio standby instance for checking DRIVER_OK as you indicate >> below, I wonder if the group ID thing will be helpful to set >> "primary-failover" flag internally without having to add another >> option in CLI? > > I haven't thought about it but it's an option. > >> > A virtual machine is then initialized with just a standby virtio >> > device. Primary is not yet added. >> > >> > Later QEMU detects that guest driver device set DRIVER_OK. >> > It then exposes the primary device to the guest, and triggers >> > a device addition event (hot-plug event) for it. >> >> Sounds OK. While there might be a small window the guest already >> starts to use virtio interface before the passthrough gets plugged in, >> I think that should be fine. >> >> Another option is to wait until the primary appears and gets >> registered in the guest, so it can bring up the upper failover >> interface. > > We can't be sure this will ever happen, can we? We might be asked to > migrate at any time. Right. For that to work, virtio driver needs a complicated state tracking hand-in-hand with the host for VF's hot plugging activity. If hot plugging is defered due to migration activity the failover interface can be brought up immediately. As said, this is just an option. I don't have strong preference here. > >> > >> > If QEMU detects guest driver removal, it initiates a hot-unplug sequence >> > to remove the primary driver. In particular, if QEMU detects guest >> > re-initialization (e.g. by detecting guest reset) it immediately removes >> > the primary device. >> >> Agreed. >> >> For legacy guest, user might prefer seeing a single passthrough device >> rather than a virtio device. I would hope there's an option to allow >> it to happen, instead of removing all passthrough devices. >> >> Regards, >> -Siwei > > I don't see a way to make it work since then you can't migrate, can you? The thing is cloud service provider might prefer sticking to the same level of service agreement (SLA) of keeping VF over migration, particularly when guest OS or kernel does not have the support.The footprint in guest OS support might NOT be prevailing in the early days. There's no point the cloud vendor can switch back and forth, as there's no way for hypervisor to detect what kernel version even OS the guest will be running ahead of time, until the guest gets fully loaded and boots up, right? -Siwei > > The way I see it, if you don't need migration, just use PT without > failover. If you do, then you either use virtio or failover if guest > supports it. > >> > >> > We can move some of this code to management as well, architecturally it >> > does not make too much sense but it might be easier implementation-wise. >> > >> > HTH >> > >> > On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote: >> >> Ping on this patch now that the kernel patches are accepted into davem's >> >> net-next tree. >> >> https://patchwork.ozlabs.org/cover/920005/ >> >> >> >> >> >> On 5/7/2018 4:09 PM, Sridhar Samudrala wrote: >> >> > This feature bit can be used by hypervisor to indicate virtio_net >> >> > device to >> >> > act as a standby for another device with the same MAC address. >> >> > >> >> > I tested this with a small change to the patch to mark the STANDBY >> >> > feature 'true' >> >> > by default as i am using libvirt to start the VMs. >> >> > Is there a way to pass the newly added feature bit 'standby' to qemu >> >> > via libvirt >> >> > XML file? >> >> > >> >> > Signed-off-by: Sridhar Samudrala >> >> > --- >> >> > hw/net/virtio-net.c | 2 ++ >> >> > include/standard-headers/linux/virtio_net.h | 3 +++ >> >> > 2 files changed, 5 insertions(+) >> >> >
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On Tue, Jun 05, 2018 at 02:16:44PM -0700, Siwei Liu wrote:
> Good to see this discussion going. I share the same feeling that the
> decision of plugging the primary (passthrough) should only be made
> until guest driver acknowledges DRIVER_OK and _F_STANDBY.
> Architecturally this intelligence should be baken to QEMU itself
> rather than moving up to management stack, such as libvirt.
>
> A few questions in line below.
>
> On Tue, Jun 5, 2018 at 5:33 AM, 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.
> >
> > And on reset or when backup is cleared in some other way, unplug the
> > primary.
> >
> > Something like the below will do the job:
> >
> > Primary device is added with a special "primary-failover" flag.
>
> I wonder if you envision this flag as a user interface or some
> internal attribute/property to QEMU device?
>
> Since QEMU needs to associate this particular primary-failover device
> with a virtio standby instance for checking DRIVER_OK as you indicate
> below, I wonder if the group ID thing will be helpful to set
> "primary-failover" flag internally without having to add another
> option in CLI?
I haven't thought about it but it's an option.
> > A virtual machine is then initialized with just a standby virtio
> > device. Primary is not yet added.
> >
> > Later QEMU detects that guest driver device set DRIVER_OK.
> > It then exposes the primary device to the guest, and triggers
> > a device addition event (hot-plug event) for it.
>
> Sounds OK. While there might be a small window the guest already
> starts to use virtio interface before the passthrough gets plugged in,
> I think that should be fine.
>
> Another option is to wait until the primary appears and gets
> registered in the guest, so it can bring up the upper failover
> interface.
We can't be sure this will ever happen, can we? We might be asked to
migrate at any time.
> >
> > If QEMU detects guest driver removal, it initiates a hot-unplug sequence
> > to remove the primary driver. In particular, if QEMU detects guest
> > re-initialization (e.g. by detecting guest reset) it immediately removes
> > the primary device.
>
> Agreed.
>
> For legacy guest, user might prefer seeing a single passthrough device
> rather than a virtio device. I would hope there's an option to allow
> it to happen, instead of removing all passthrough devices.
>
> Regards,
> -Siwei
I don't see a way to make it work since then you can't migrate, can you?
The way I see it, if you don't need migration, just use PT without
failover. If you do, then you either use virtio or failover if guest
supports it.
> >
> > We can move some of this code to management as well, architecturally it
> > does not make too much sense but it might be easier implementation-wise.
> >
> > HTH
> >
> > On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote:
> >> Ping on this patch now that the kernel patches are accepted into davem's
> >> net-next tree.
> >> https://patchwork.ozlabs.org/cover/920005/
> >>
> >>
> >> On 5/7/2018 4:09 PM, Sridhar Samudrala wrote:
> >> > This feature bit can be used by hypervisor to indicate virtio_net device
> >> > to
> >> > act as a standby for another device with the same MAC address.
> >> >
> >> > I tested this with a small change to the patch to mark the STANDBY
> >> > feature 'true'
> >> > by default as i am using libvirt to start the VMs.
> >> > Is there a way to pass the newly added feature bit 'standby' to qemu via
> >> > libvirt
> >> > XML file?
> >> >
> >> > Signed-off-by: Sridhar Samudrala
> >> > ---
> >> > hw/net/virtio-net.c | 2 ++
> >> > include/standard-headers/linux/virtio_net.h | 3 +++
> >> > 2 files changed, 5 insertions(+)
> >> >
> >> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >> > index 90502fca7c..38b3140670 100644
> >> > --- a/hw/net/virtio-net.c
> >> > +++ b/hw/net/virtio-net.c
> >> > @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
> >> >true),
> >> > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed,
> >> > SPEED_UNKNOWN),
> >> > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
> >> > +DEFINE_PROP_BIT64("standby", VirtIONet, host_features,
> >> > VIRTIO_NET_F_STANDBY,
> >> > + false),
> >> > DEFINE_PROP_END_OF_LIST(),
> >> > };
> >> > diff --git a/include/standard-headers/linux/virtio_net.h
> >> > b/include/standard-headers/linux/virtio_net.h
> >> > index e9f255ea3f..01ec09684c 100644
> >> > --- a/include/standard-headers/linux/virtio_net.h
> >> > +++ b/include/standard-headers/linux/virtio_net.h
> >> > @@ -57,6 +57,9 @@
> >> > * Steering
Re: [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
Good to see this discussion going. I share the same feeling that the
decision of plugging the primary (passthrough) should only be made
until guest driver acknowledges DRIVER_OK and _F_STANDBY.
Architecturally this intelligence should be baken to QEMU itself
rather than moving up to management stack, such as libvirt.
A few questions in line below.
On Tue, Jun 5, 2018 at 5:33 AM, 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.
>
> And on reset or when backup is cleared in some other way, unplug the
> primary.
>
> Something like the below will do the job:
>
> Primary device is added with a special "primary-failover" flag.
I wonder if you envision this flag as a user interface or some
internal attribute/property to QEMU device?
Since QEMU needs to associate this particular primary-failover device
with a virtio standby instance for checking DRIVER_OK as you indicate
below, I wonder if the group ID thing will be helpful to set
"primary-failover" flag internally without having to add another
option in CLI?
> A virtual machine is then initialized with just a standby virtio
> device. Primary is not yet added.
>
> Later QEMU detects that guest driver device set DRIVER_OK.
> It then exposes the primary device to the guest, and triggers
> a device addition event (hot-plug event) for it.
Sounds OK. While there might be a small window the guest already
starts to use virtio interface before the passthrough gets plugged in,
I think that should be fine.
Another option is to wait until the primary appears and gets
registered in the guest, so it can bring up the upper failover
interface.
>
> If QEMU detects guest driver removal, it initiates a hot-unplug sequence
> to remove the primary driver. In particular, if QEMU detects guest
> re-initialization (e.g. by detecting guest reset) it immediately removes
> the primary device.
Agreed.
For legacy guest, user might prefer seeing a single passthrough device
rather than a virtio device. I would hope there's an option to allow
it to happen, instead of removing all passthrough devices.
Regards,
-Siwei
>
> We can move some of this code to management as well, architecturally it
> does not make too much sense but it might be easier implementation-wise.
>
> HTH
>
> On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote:
>> Ping on this patch now that the kernel patches are accepted into davem's
>> net-next tree.
>> https://patchwork.ozlabs.org/cover/920005/
>>
>>
>> On 5/7/2018 4:09 PM, Sridhar Samudrala wrote:
>> > This feature bit can be used by hypervisor to indicate virtio_net device to
>> > act as a standby for another device with the same MAC address.
>> >
>> > I tested this with a small change to the patch to mark the STANDBY feature
>> > 'true'
>> > by default as i am using libvirt to start the VMs.
>> > Is there a way to pass the newly added feature bit 'standby' to qemu via
>> > libvirt
>> > XML file?
>> >
>> > Signed-off-by: Sridhar Samudrala
>> > ---
>> > hw/net/virtio-net.c | 2 ++
>> > include/standard-headers/linux/virtio_net.h | 3 +++
>> > 2 files changed, 5 insertions(+)
>> >
>> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>> > index 90502fca7c..38b3140670 100644
>> > --- a/hw/net/virtio-net.c
>> > +++ b/hw/net/virtio-net.c
>> > @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
>> >true),
>> > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
>> > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
>> > +DEFINE_PROP_BIT64("standby", VirtIONet, host_features,
>> > VIRTIO_NET_F_STANDBY,
>> > + false),
>> > DEFINE_PROP_END_OF_LIST(),
>> > };
>> > diff --git a/include/standard-headers/linux/virtio_net.h
>> > b/include/standard-headers/linux/virtio_net.h
>> > index e9f255ea3f..01ec09684c 100644
>> > --- a/include/standard-headers/linux/virtio_net.h
>> > +++ b/include/standard-headers/linux/virtio_net.h
>> > @@ -57,6 +57,9 @@
>> > * Steering */
>> > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>> > +#define VIRTIO_NET_F_STANDBY 62/* Act as standby for another
>> > device
>> > + * with the same MAC.
>> > + */
>> > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and
>> > duplex */
>> > #ifndef VIRTIO_NET_NO_LEGACY
>
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
>
