Linux Virtualization - Jun 2018 - [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net

On Tue, Jun 26, 2018 at 5:29 PM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Tue, Jun 26, 2018 at 04:38:26PM -0700, Siwei Liu wrote:
>> On Mon, Jun 25, 2018 at 6:50 PM, Michael S. Tsirkin <mst at
redhat.com> wrote:
>> > On Mon, Jun 25, 2018 at 10:54:09AM -0700, Samudrala, Sridhar
wrote:
>> >> > > > > 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.
>> >>
>> >> Yes. The MAC address is assigned by the hypervisor and it
needs to manage the movement
>> >> of the MAC between the PF and VF.  Allowing the guest to
change the MAC will require
>> >> synchronization between the hypervisor and the PF/VF drivers.
Most of the VF drivers
>> >> don't allow changing guest MAC unless it is a trusted VF.
>> >
>> > OK but it's a policy thing. Maybe it's a trusted VF. Who
knows?
>> > For example I can see host just
>> > failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block it.
>> > I'm not sure why VIRTIO_NET_F_STANDBY has to block it in the
guest.
>>
>> That's why I think pairing using MAC is fragile IMHO. When VF's
MAC
>> got changed before virtio attempts to match and pair the device, it
>> ends up with no pairing found out at all.
>
> Guest seems to match on the hardware mac and ignore whatever
> is set by user. Makes sense to me and should not be fragile.
Host can change the hardware mac for VF any time.

-Siwei
>
>
>> UUID is better.
>>
>> -Siwei
>>
>> >
>> > --
>> > MST

On 6/26/2018 11:21 PM, Siwei Liu wrote:
> On Tue, Jun 26, 2018 at 5:29 PM, Michael S. Tsirkin <mst at
redhat.com> wrote:
>> On Tue, Jun 26, 2018 at 04:38:26PM -0700, Siwei Liu wrote:
>>> On Mon, Jun 25, 2018 at 6:50 PM, Michael S. Tsirkin <mst at
redhat.com> wrote:
>>>> On Mon, Jun 25, 2018 at 10:54:09AM -0700, Samudrala, Sridhar
wrote:
>>>>>>>>> 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.
>>>>> Yes. The MAC address is assigned by the hypervisor and it
needs to manage the movement
>>>>> of the MAC between the PF and VF.  Allowing the guest to
change the MAC will require
>>>>> synchronization between the hypervisor and the PF/VF
drivers. Most of the VF drivers
>>>>> don't allow changing guest MAC unless it is a trusted
VF.
>>>> OK but it's a policy thing. Maybe it's a trusted VF.
Who knows?
>>>> For example I can see host just
>>>> failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block it.
>>>> I'm not sure why VIRTIO_NET_F_STANDBY has to block it in
the guest.
>>> That's why I think pairing using MAC is fragile IMHO. When
VF's MAC
>>> got changed before virtio attempts to match and pair the device, it
>>> ends up with no pairing found out at all.
>> Guest seems to match on the hardware mac and ignore whatever
>> is set by user. Makes sense to me and should not be fragile.
> Host can change the hardware mac for VF any time.
Live migration is initiated and controlled by the Host,? So the Source Host will
reset the MAC during live migration after unplugging the VF. This is to redirect
the
VMs frames towards PF so that they can be received via virtio-net standby
interface.
The destination host will set the VF MAC and plug the VF after live migration is
completed.

Allowing the guest to change the MAC will require the qemu/libvirt/mgmt layers
to
track the MAC changes and replay that change after live migration.

>
> -Siwei
>>
>>> UUID is better.
>>>
>>> -Siwei
>>>
>>>> --
>>>> MST

On Tue, Jun 26, 2018 at 11:49 PM, Samudrala, Sridhar
<sridhar.samudrala at intel.com> wrote:
> On 6/26/2018 11:21 PM, Siwei Liu wrote:
>>
>> On Tue, Jun 26, 2018 at 5:29 PM, Michael S. Tsirkin <mst at
redhat.com>
>> wrote:
>>>
>>> On Tue, Jun 26, 2018 at 04:38:26PM -0700, Siwei Liu wrote:
>>>>
>>>> On Mon, Jun 25, 2018 at 6:50 PM, Michael S. Tsirkin <mst at
redhat.com>
>>>> wrote:
>>>>>
>>>>> On Mon, Jun 25, 2018 at 10:54:09AM -0700, Samudrala,
Sridhar wrote:
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>
>>>>>> Yes. The MAC address is assigned by the hypervisor and
it needs to
>>>>>> manage the movement
>>>>>> of the MAC between the PF and VF.  Allowing the guest
to change the
>>>>>> MAC will require
>>>>>> synchronization between the hypervisor and the PF/VF
drivers. Most of
>>>>>> the VF drivers
>>>>>> don't allow changing guest MAC unless it is a
trusted VF.
>>>>>
>>>>> OK but it's a policy thing. Maybe it's a trusted
VF. Who knows?
>>>>> For example I can see host just
>>>>> failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block
it.
>>>>> I'm not sure why VIRTIO_NET_F_STANDBY has to block it
in the guest.
>>>>
>>>> That's why I think pairing using MAC is fragile IMHO. When
VF's MAC
>>>> got changed before virtio attempts to match and pair the
device, it
>>>> ends up with no pairing found out at all.
>>>
>>> Guest seems to match on the hardware mac and ignore whatever
>>> is set by user. Makes sense to me and should not be fragile.
>>
>> Host can change the hardware mac for VF any time.
>
>
> Live migration is initiated and controlled by the Host,  So the Source Host
> will
> reset the MAC during live migration after unplugging the VF. This is to
> redirect the
> VMs frames towards PF so that they can be received via virtio-net standby
> interface.
> The destination host will set the VF MAC and plug the VF after live
> migration is
> completed.
>
> Allowing the guest to change the MAC will require the qemu/libvirt/mgmt
> layers to
> track the MAC changes and replay that change after live migration.
>
If the failover's MAC is kept in sync with VF's MAC address change,
the VF on destination host can be paired using the permanent address
after plugging in, while failover interface will resync the MAC to the
current one in use when enslaving the VF. I think similar is done for
multicast and unicast address list on VF's registration, right? No
need of QEMU or mgmt software keep track of MAC changes.

-Siwei
>
>
>>
>> -Siwei
>>>
>>>
>>>> UUID is better.
>>>>
>>>> -Siwei
>>>>
>>>>> --
>>>>> MST
>
>