Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Sameeh Jubran <sameeh@daynix.com>
Cc: cohuck@redhat.com, virtio-dev <virtio-dev@lists.oasis-open.org>
Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature
Date: Tue, 18 Sep 2018 22:03:04 -0700	[thread overview]
Message-ID: <0aa3b8a6-68d4-3275-bb3c-2b2d69be18cc@intel.com> (raw)
In-Reply-To: <20180918091231-mutt-send-email-mst@kernel.org>

On 9/18/2018 6:25 AM, Michael S. Tsirkin wrote:
> On Tue, Sep 18, 2018 at 01:37:35PM +0300, Sameeh Jubran wrote:
>> On Tue, Sep 18, 2018 at 1:21 PM Cornelia Huck <cohuck@redhat.com> wrote:
>>> On Wed, 12 Sep 2018 11:22:12 -0400
>>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>>
>>>> On Wed, Sep 12, 2018 at 08:17:45AM -0700, Samudrala, Sridhar wrote:
>>>>>
>>>>> On 9/7/2018 2:34 PM, Michael S. Tsirkin wrote:
>>>>>> On Wed, Aug 15, 2018 at 11:49:15AM -0700, Sridhar Samudrala wrote:
>>>>>>> VIRTIO_NET_F_STANDBY feature enables hypervisor to indicate virtio_net
>>>>>>> device to act as a standby for another device with the same MAC address.
>>>>>>>
>>>>>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>>>>>> Acked-by: Cornelia Huck <cohuck@redhat.com>
>>>>>>> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/18
>>>>>> Applied but when do you plan to add documentation as pointed
>>>>>> out by Jan and Halil?
>>>>> I thought additional documentation will be done as part of the Qemu enablement
>>>>> patches and i hope someone in RH is looking into it.
>>>>>
>>>>> Does it make sense to add a link to to the kernel documentation of this feature in
>>>>> the spec
>>>>>   https://www.kernel.org/doc/html/latest/networking/net_failover.html
>>>>
>>>> I do not think this will address the comments posted.  Specifically we
>>>> should probably include documentation for what is a standby and primary:
>>>> what is expected of driver (maintain configuration on standby, support
>>>> primary coming and going, transmit on standby only if there is no
>>>> primary) and of device (have same mac for standby as for standby).
>>> Yes, we need some definitive statements of what a driver and a device
>>> is supposed to do in order to conform; it might make sense to discuss
>>> this in conjunction with discussion on any QEMU patches (have not
>>> checked whether anything has been posted, just returned from vacation).
>>>
>>> I assume that we still stick with the plan to implement/document
>>> MAC-based handling first and then enhance with other methods later?
>> I am currently in the process of writing the patches for this feature,
>> I have thought about how the feature should be implemented
>> and decided to go with a different approach. I've decided that the id
>> of the vfio attached device will be specified in the virtio-net
>> arguments as follows:
>>
>> -device virtio-net,standby=<device_id_of_vfio_device>
>> -vfio #address,id=<device_id_of_vfio_device>
>>
>> This approach makes minimal changes to the current infrastructure and
>> does so elegantly without adding unnecessary ids to the bridges.
>>
>> The mac address approach seems to be very complicated as there is no
>> standard way to find the mac address of a given device and it is
>> vendor dependent,
>> which makes the task of identifying the target standby device by it's
>> mac address a very tough one.
> Oh mac address is used by guest. I agree it's not a great qemu
> interface.
> The idea was basically to have -vfio #address,primary=<id>
>
>
>> Please share your thoughts so I'll move forward with the patches.
> Can this actually support hotplug add and remove of the vfio device though?
> E.g. hotplug add vfio device while VM is already running?
> With the primary=<> it works because standby must always exist
> even when primary isn't there.

Also, how do we want to handle a scenario where a VM has a direct attached VF
device and virtio-net in standby mode is hotplugged/unplugged?

What should be the behavior if guest unloads a virtio-net driver that is acting
as a standby? Do we want qemu to unplug VF device too?


>
>
>> An initial patch which implements hiding the device from pci bus
>> before the feature is acked is provided below:
>>
>> commit b716371bf4807fe16ffb4ffd901b69a110902a3c (HEAD -> failover)
>> Author: Sameeh Jubran <sjubran@redhat.com>
>> Date:   Sun Sep 16 13:21:41 2018 +0300
>>
>>      virtio-net: Implement standby feature
>>
>>      Signed-off-by: Sameeh Jubran <sjubran@redhat.com>
>>
>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>> index f154756e85..46386c0e1b 100644
>> --- a/hw/net/virtio-net.c
>> +++ b/hw/net/virtio-net.c
>> @@ -26,7 +26,9 @@
>>   #include "qapi/qapi-events-net.h"
>>   #include "hw/virtio/virtio-access.h"
>>   #include "migration/misc.h"
>> +#include "hw/pci/pci.h"
>>   #include "standard-headers/linux/ethtool.h"
>> +#include "hw/vfio/vfio-common.h"
>>
>>   #define VIRTIO_NET_VM_VERSION    11
>>
>> @@ -1946,6 +1948,13 @@ void virtio_net_set_netclient_name(VirtIONet
>> *n, const char *name,
>>       n->netclient_type = g_strdup(type);
>>   }
>>
>> +static bool standby_device_present(VirtIONet *n, const char *id,
>> +        struct PCIDevice **pdev)
>> +{
>> +    return pci_qdev_find_device(id, pdev) >= 0 && pdev &&
>> +    vfio_is_vfio_pci(*pdev);
>> +}
>> +
>>   static void virtio_net_device_realize(DeviceState *dev, Error **errp)
>>   {
>>       VirtIODevice *vdev = VIRTIO_DEVICE(dev);
>> @@ -1976,6 +1985,21 @@ static void
>> virtio_net_device_realize(DeviceState *dev, Error **errp)
>>           n->host_features |= (1ULL << VIRTIO_NET_F_SPEED_DUPLEX);
>>       }
>>
>> +    if (n->net_conf.standby_id_str && standby_device_present(n,
>> +                n->net_conf.standby_id_str, &n->standby_pdev)) {
>> +        DeviceState *dev = DEVICE(n->standby_pdev);
>> +        DeviceClass *klass = DEVICE_GET_CLASS(dev);
>> +        /* Hide standby from pci till the feature is acked */
>> +        if (klass->hotpluggable)
>> +        {
>> +            qdev_unplug(dev, errp);
>
> Does this really hide the device?
> I see:
>      hdc = HOTPLUG_HANDLER_GET_CLASS(hotplug_ctrl);
>      if (hdc->unplug_request) {
>          hotplug_handler_unplug_request(hotplug_ctrl, dev, errp);
>      } else {
>          hotplug_handler_unplug(hotplug_ctrl, dev, errp);
>      }
>
> which seems to just send an eject request to guest - the reverse of
> what we want to do.
>
>> +            if (errp == NULL)
>> +            {
>> +                n->host_features |= (1ULL << VIRTIO_NET_F_STANDBY);
>> +            }
> I'm not sure how is this error handling supposed to work.
>
>> +        }
>> +    }
>> +
>>       virtio_net_set_config_size(n, n->host_features);
>>       virtio_init(vdev, "virtio-net", VIRTIO_ID_NET, n->config_size);
>>
>> @@ -2198,6 +2222,7 @@ 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_STRING("standby", VirtIONet, net_conf.standby_id_str),
>>       DEFINE_PROP_END_OF_LIST(),
>>   };
>>
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index 866f0deeb7..593debe56e 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -220,6 +220,12 @@ static void vfio_intx_disable_kvm(VFIOPCIDevice *vdev)
>>   #endif
>>   }
>>
>> +bool vfio_is_vfio_pci(PCIDevice* pdev)
>> +{
>> +    VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
>> +    return vdev->vbasedev.type == VFIO_DEVICE_TYPE_PCI;
>> +}
>> +
>>   static void vfio_intx_update(PCIDevice *pdev)
>>   {
>>       VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>> index 821def0565..26dfde805f 100644
>> --- a/include/hw/vfio/vfio-common.h
>> +++ b/include/hw/vfio/vfio-common.h
>> @@ -195,5 +195,6 @@ int vfio_spapr_create_window(VFIOContainer *container,
>>                                hwaddr *pgsize);
>>   int vfio_spapr_remove_window(VFIOContainer *container,
>>                                hwaddr offset_within_address_space);
>> +bool vfio_is_vfio_pci(PCIDevice* pdev);
>>
>>   #endif /* HW_VFIO_VFIO_COMMON_H */
>> diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
>> index 4d7f3c82ca..94388b40cb 100644
>> --- a/include/hw/virtio/virtio-net.h
>> +++ b/include/hw/virtio/virtio-net.h
>> @@ -42,6 +42,7 @@ typedef struct virtio_net_conf
>>       int32_t speed;
>>       char *duplex_str;
>>       uint8_t duplex;
>> +    char *standby_id_str;
>>   } virtio_net_conf;
>>
>>   /* Maximum packet size we can receive from tap device: header + 64k */
>> @@ -103,6 +104,7 @@ typedef struct VirtIONet {
>>       int announce_counter;
>>       bool needs_vnet_hdr_swap;
>>       bool mtu_bypass_backend;
>> +    PCIDevice *standby_pdev;
>>   } VirtIONet;
>>
>>   void virtio_net_set_netclient_name(VirtIONet *n, const char *name,
>> (END)
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>>>
>>
>> -- 
>> Respectfully,
>> Sameeh Jubran
>> Linkedin
>> Software Engineer @ Daynix.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2018-09-19  5:05 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 18:49 [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature Sridhar Samudrala
2018-08-27  8:40 ` [virtio-dev] " Cornelia Huck
2018-08-27 12:34   ` Michael S. Tsirkin
2018-08-27 16:50     ` Samudrala, Sridhar
2018-08-28 12:13       ` Michael S. Tsirkin
2018-09-07 21:34 ` [virtio-dev] " Michael S. Tsirkin
2018-09-12 15:17   ` Samudrala, Sridhar
2018-09-12 15:22     ` Michael S. Tsirkin
2018-09-18 10:20       ` Cornelia Huck
2018-09-18 10:37         ` Sameeh Jubran
2018-09-18 13:25           ` Michael S. Tsirkin
2018-09-18 18:30             ` Siwei Liu
2018-09-18 18:39               ` Michael S. Tsirkin
2018-09-18 19:10                 ` Siwei Liu
2018-09-20  3:04                   ` Michael S. Tsirkin
2018-09-19  5:03             ` Samudrala, Sridhar [this message]
2018-09-20  5:51             ` Sameeh Jubran
2018-09-18 13:35         ` Michael S. Tsirkin
2018-09-18 15:13           ` Venu Busireddy
2018-09-18 15:31             ` Michael S. Tsirkin
2018-09-18 18:48               ` Siwei Liu
2018-09-20  3:11                 ` Michael S. Tsirkin
2018-09-20 23:57                   ` Siwei Liu
2018-09-21  2:23                     ` Michael S. Tsirkin
2018-09-21  2:34                       ` Michael S. Tsirkin
2018-09-27  0:18                       ` Siwei Liu
2018-09-27  7:17                         ` Sameeh Jubran
2018-09-27 16:17                           ` Michael S. Tsirkin
2018-09-27 17:23                             ` Samudrala, Sridhar
2018-09-27 23:45                               ` Michael S. Tsirkin
2018-09-30  9:17                               ` Sameeh Jubran
2018-09-30 13:50                                 ` Sameeh Jubran
2018-09-27 16:32                         ` Michael S. Tsirkin
2018-10-02  8:42                           ` Siwei Liu
2018-10-02 12:43                             ` Michael S. Tsirkin
2018-10-05  0:03                               ` Siwei Liu
2018-10-05  5:17                                 ` Samudrala, Sridhar
2018-10-10 14:40                                   ` Michael S. Tsirkin
2018-10-11  0:16                                     ` Samudrala, Sridhar
2018-10-05 19:18                                 ` Michael S. Tsirkin
2018-10-08 22:06                                   ` Sameeh Jubran
2018-10-10 14:43                                     ` Michael S. Tsirkin
2018-10-11  1:26                                   ` Siwei Liu
2018-10-18 23:20                                     ` Siwei Liu
2018-10-18 23:40                                       ` Michael S. Tsirkin
2018-10-19  3:45                                     ` Michael S. Tsirkin
2018-11-21 15:39                                       ` Sameeh Jubran
2018-11-21 18:41                                         ` Michael S. Tsirkin
2018-11-21 20:04                                           ` Sameeh Jubran
2018-11-21 23:51                                             ` Samudrala, Sridhar
2018-11-22 13:55                                               ` Sameeh Jubran
2018-11-22 18:27                                             ` Michael S. Tsirkin
2018-11-26 15:13                                               ` Sameeh Jubran
2018-11-26 15:43                                                 ` Sameeh Jubran
2018-11-26 20:22                                                   ` Samudrala, Sridhar
2018-11-27 11:24                                                     ` Sameeh Jubran
2018-11-28 17:08                                                     ` Michael S. Tsirkin
2018-11-28 17:31                                                       ` Samudrala, Sridhar
2018-11-28 17:35                                                         ` Michael S. Tsirkin
2018-11-28 18:39                                                           ` Samudrala, Sridhar
2018-11-28 18:51                                                             ` Michael S. Tsirkin
2018-11-29  6:29                                                               ` Samudrala, Sridhar
2018-11-28 20:06                                                             ` Michael S. Tsirkin
2018-11-28 20:28                                                               ` si-wei liu
2018-11-28 20:43                                                                 ` Michael S. Tsirkin
2018-11-28 20:47                                                                   ` si-wei liu
2018-11-29  1:15                                                                 ` Michael S. Tsirkin
2018-11-29  6:37                                                                   ` Samudrala, Sridhar
2018-11-29 20:14                                                                   ` si-wei liu
2018-11-29 21:17                                                                     ` Michael S. Tsirkin
2018-11-29 22:53                                                                       ` si-wei liu
2018-11-29 23:53                                                                         ` Samudrala, Sridhar
2018-11-30  0:24                                                                           ` si-wei liu
2018-11-30  3:08                                                                             ` Samudrala, Sridhar
2018-11-30  4:46                                                                               ` si-wei liu
2018-11-30  6:21                                                                         ` Michael S. Tsirkin
2018-12-04  2:09                                                                           ` si-wei liu
2018-12-04  3:59                                                                             ` Michael S. Tsirkin
2018-12-05 16:18                                                                               ` Sameeh Jubran
2018-12-05 17:18                                                                                 ` Michael S. Tsirkin
2018-12-08  1:54                                                                                 ` si-wei liu
2018-12-10 15:13                                                                                   ` Sameeh Jubran
2018-12-10 15:34                                                                                     ` Sameeh Jubran
2018-12-10 17:46                                                                                       ` Michael S. Tsirkin
2018-12-11 15:50                                                                                         ` Sameeh Jubran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0aa3b8a6-68d4-3275-bb3c-2b2d69be18cc@intel.com \
    --to=sridhar.samudrala@intel.com \
    --cc=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=sameeh@daynix.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox