netdev - Re: [RFC] virtio-net: help live migrate SR-IOV devices

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 1 Dec 2017 12:08:59 -0800
From:   Shannon Nelson <shannon.nelson@...cle.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>,
        achiad shochat <achiad.mellanox@...il.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        virtualization@...ts.linux-foundation.org,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>,
        Achiad <achiad@...lanox.com>,
        Peter Waskiewicz Jr <peter.waskiewicz.jr@...el.com>,
        "Singhai, Anjali" <anjali.singhai@...el.com>,
        Andy Gospodarek <gospo@...adcom.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Hannes Frederic Sowa <hannes@...hat.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] virtio-net: help live migrate SR-IOV devices

On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote:
> On Thu, Nov 30, 2017 at 10:08:45AM +0200, achiad shochat wrote:
>> Re. problem #2:
>> Indeed the best way to address it seems to be to enslave the VF driver
>> netdev under a persistent anchor netdev.
>> And it's indeed desired to allow (but not enforce) PV netdev and VF
>> netdev to work in conjunction.
>> And it's indeed desired that this enslavement logic work out-of-the box.
>> But in case of PV+VF some configurable policies must be in place (and
>> they'd better be generic rather than differ per PV technology).
>> For example - based on which characteristics should the PV+VF coupling
>> be done? netvsc uses MAC address, but that might not always be the
>> desire.
> 
> It's a policy but not guest userspace policy.
> 
> The hypervisor certainly knows.
> 
> Are you concerned that someone might want to create two devices with the
> same MAC for an unrelated reason?  If so, hypervisor could easily set a
> flag in the virtio device to say "this is a backup, use MAC to find
> another device".

This is something I was going to suggest: a flag or other configuration 
on the virtio device to help control how this new feature is used.  I 
can imagine this might be useful to control from either the hypervisor 
side or the VM side.

The hypervisor might want to (1) disable it (force it off), (2) enable 
it for VM choice, or (3) force it on for the VM.  In case (2), the VM 
might be able to chose whether it wants to make use of the feature, or 
stick with the bonding solution.

Either way, the kernel is making a feature available, and the user (VM 
or hypervisor) is able to control it by selecting the feature based on 
the policy desired.

sln