On Fri, Jun 22, 2018 at 4:40 PM, Siwei Liu [off-list ref] wrote:

On Fri, Jun 22, 2018 at 3:25 PM, Michael S. Tsirkin [off-list ref] wrote:

quoted

On Fri, Jun 22, 2018 at 02:51:11PM -0700, Siwei Liu wrote:

quoted

On Fri, Jun 22, 2018 at 2:29 PM, Michael S. Tsirkin [off-list ref] wrote:

quoted

On Fri, Jun 22, 2018 at 01:03:04PM -0700, Siwei Liu wrote:

quoted

On Fri, Jun 22, 2018 at 1:00 PM, Siwei Liu [off-list ref] wrote:

quoted

On Thu, Jun 21, 2018 at 7:32 PM, Michael S. Tsirkin [off-list ref] wrote:

quoted

On Thu, Jun 21, 2018 at 06:21:55PM -0700, Siwei Liu wrote:

quoted

On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck [off-list ref] wrote:

quoted

On Wed, 20 Jun 2018 22:48:58 +0300
"Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:

quoted

In any case, I'm not sure anymore why we'd want the extra uuid.

It's mostly so we can have e.g. multiple devices with same MAC
(which some people seem to want in order to then use
then with different containers).

But it is also handy for when you assign a PF, since then you
can't set the MAC.

OK, so what about the following:

- introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
  that we have a new uuid field in the virtio-net config space
- in QEMU, add a property for virtio-net that allows to specify a uuid,
  offer VIRTIO_NET_F_STANDBY_UUID if set
- when configuring, set the property to the group UUID of the vfio-pci
  device

If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
to still expose UUID in the config space on virtio-pci?

Yes but guest is not supposed to read it.

quoted

I'm not even sure if it's sane to expose group UUID on the PCI bridge
where the corresponding vfio-pci device attached to for a guest which
doesn't support the feature (legacy).

-Siwei

Yes but you won't add the primary behind such a bridge.

I assume the UUID feature is a new one besides the exiting
VIRTIO_NET_F_STANDBY feature, where I think the current proposal is,
if UUID feature is present and supported by guest, we'll do pairing
based on UUID; if UUID feature present

                                 ^^^^^^^  is NOT present

Let's go back for a bit.

What is wrong with matching by mac?

1. Does not allow multiple NICs with same mac
2. Requires MAC to be programmed by host in the PT device
   (which is often possible with VFs but isn't possible with all PT
   devices)

Might not neccessarily be something wrong, but it's very limited to
prohibit the MAC of VF from changing when enslaved by failover.

You mean guest changing MAC? I'm not sure why we prohibit that.

I think Sridhar and Jiri might be better person to answer it. My
impression was that sync'ing the MAC address change between all 3
devices is challenging, as the failover driver uses MAC address to
match net_device internally.

quoted

quoted

The
same as you indicated on the PT device. I suspect the same is
prohibited on even virtio-net and failover is because of the same
limitation.

quoted

Both issues are up to host: if host needs them it needs the UUID
feature, if not MAC matching is sufficient.

I know. What I'm saying is that we rely on STANDBY feature to control
the visibility of the primary, not the UUID feature.

-Siwei

And what I'm saying is that it's up to a host policy.

So lets say host policy explicitly requires UUID but the guest does
not support it. The guest could be a legacy guest with no STANDBY
support, or a relevately recent guest with STANDBY support but without
the UUID support. In either case, since host asked for UUID matching
explicitly, maybe because it requires different NIC using same MAC, so
it has to override the negotiation result of STANDBY, even if STANDBY
is set and supported? That will end up with inter-feature dependency
over STANDBY, as you see.

I forgot to mention the above has the assumption that we expose both
STANDBY and UUID feature to QEMU user. In fact, as we're going towards
not exposing the STANDBY feature directly to user, UUID may be always
required to enable STANDBY. If not, how do we make sure QEMU can
control the visibility of primary device? Something to be confirmed
before implementing the code.

-Siwei

-Siwei

quoted

quoted

quoted

quoted

quoted

or not supported by guest,
we'll still plug in the VF (if guest supports the _F_STANDBY feature)
but the pairing will be fallback to using MAC address. Are you saying
you don't even want to plug in the primary when the UUID feature is
not supported by guest? Does the feature negotiation UUID have to
depend on STANDBY being set, or the other way around? I thought that
just the absence of STANDBY will prevent primary to get exposed to the
guest.

-Siwei

quoted

quoted

quoted

- in the guest, use the uuid from the virtio-net device's config space
  if applicable; else, fall back to matching by MAC as done today