netdev - Re: [virtio-dev] Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a628e3ed-3250-07a0-866a-a09909f9c642@intel.com>
Date:   Fri, 2 Mar 2018 12:56:21 -0800
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Siwei Liu <loseweigh@...il.com>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Alexander Duyck <alexander.duyck@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Stephen Hemminger <stephen@...workplumber.org>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>, virtio-dev@...ts.oasis-open.org,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
        Jakub Kicinski <kubakici@...pl>
Subject: Re: [virtio-dev] Re: [PATCH v4 2/2] virtio_net: Extend virtio to use
 VF datapath when available



On 3/2/2018 12:44 PM, Siwei Liu wrote:
> On Fri, Mar 2, 2018 at 12:10 PM, Michael S. Tsirkin <mst@...hat.com> wrote:
>> On Fri, Mar 02, 2018 at 11:52:27AM -0800, Samudrala, Sridhar wrote:
>>>
>>> On 3/2/2018 11:41 AM, Michael S. Tsirkin wrote:
>>>> On Fri, Mar 02, 2018 at 07:26:25AM -0800, Alexander Duyck wrote:
>>>>> The design limits things to a 1:1 relationship since we just have the
>>>>> child and backup pointers, but I don't think I am seeing exception
>>>>> handling to prevent us from overwriting the child pointers so there
>>>>> may be a leak there.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> - Alex
>>>> In fact maintaining a list in that case would be nicer, and
>>>> just use an arbitrary one.
>>>> E.g. one can see how a user wanting to swap device 1 for device 2
>>>> might first add device 2 with same MAC then drop device 1.
>>> It should be possible to swap VF1 with VF2 by
>>> 1.- enabling virtio link
>>> 2.- unplugging VF1
>>> 3.- plugging VF2
>>> 4.- disabling virtio link
>>>
>> True, but it isn't hard to avoid breakage if user
>> swapped steps 2 and 3. No need to make it more
>> fragile that it has to be.
> The migration case, VF2 is associated with another PF on another
> machine (destination), I wonder how it is possible.
>
> Even with local plugging of VF2 on the same PF, the MAC address
> requirement (VF1's == VF2's) would fail the MAC address assignment on
> VF2.
>
>
I didn't include updating the MAC filter step in the above sequence.
So definitely plugging 2 VFs with the same MAC address will be an issue.

Here is the more complete sequence of steps that are required to
enable live migration.

Source Hypervisor
- Bring up the virtio link
- Hot Unplug VF from the VM
- Delete FDB entry for the MAC on the Bridge associated with virtio/tap
- Remove the MAC filter associated with the VF
- Migrate VM to destination

Destination Hypervisor (after migration is completed)
- Set MAC filter for the VF
- Hot Plug VF to the VM
- Bring down the virtio link

Thanks
Sridhar