[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180228151131.GF19654@nanopsycho>
Date: Wed, 28 Feb 2018 16:11:31 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Jakub Kicinski <kubakici@...pl>,
Alexander Duyck <alexander.duyck@...il.com>,
Sridhar Samudrala <sridhar.samudrala@...el.com>,
Stephen Hemminger <stephen@...workplumber.org>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
virtio-dev@...ts.oasis-open.org,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
"Duyck, Alexander H" <alexander.h.duyck@...el.com>,
Jason Wang <jasowang@...hat.com>,
Siwei Liu <loseweigh@...il.com>
Subject: Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a
passthru device
Wed, Feb 28, 2018 at 03:32:44PM CET, mst@...hat.com wrote:
>On Wed, Feb 28, 2018 at 08:08:39AM +0100, Jiri Pirko wrote:
>> Tue, Feb 27, 2018 at 10:41:49PM CET, kubakici@...pl wrote:
>> >On Tue, 27 Feb 2018 13:16:21 -0800, Alexander Duyck wrote:
>> >> Basically we need some sort of PCI or PCIe topology mapping for the
>> >> devices that can be translated into something we can communicate over
>> >> the communication channel.
>> >
>> >Hm. This is probably a completely stupid idea, but if we need to
>> >start marshalling configuration requests/hints maybe the entire problem
>> >could be solved by opening a netlink socket from hypervisor? Even make
>> >teamd run on the hypervisor side...
>>
>> Interesting. That would be more trickier then just to fwd 1 genetlink
>> socket to the hypervisor.
>>
>> Also, I think that the solution should handle multiple guest oses. What
>> I'm thinking about is some generic bonding description passed over some
>> communication channel into vm. The vm either use it for configuration,
>> or ignores it if it is not smart enough/updated enough.
>
>For sure, we could build virtio-bond to pass that info to guests.
What do you mean by "virtio-bond". virtio_net extension?
>
>Such an advisory mechanism would not be a replacement for the mandatory
>passthrough fallback flag proposed, but OTOH it's much more flexible.
>
>--
>MST
Powered by blists - more mailing lists