From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Qemu-devel] Re: Guest bridge setup variations Date: Thu, 10 Dec 2009 20:20:26 +0000 Message-ID: <200912102020.26724.arnd@arndb.de> References: <200912081707.42660.arnd@arndb.de> <200912101518.36128.arnd@arndb.de> <784CAF36-3F28-4FFD-82A2-0A4E54EDB831@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <784CAF36-3F28-4FFD-82A2-0A4E54EDB831@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: qemu-devel@nongnu.org Cc: "Fischer, Anna" , "virtualization@lists.linux-foundation.org" List-Id: virtualization@lists.linuxfoundation.org On Thursday 10 December 2009 19:14:28 Alexander Graf wrote: > > This is something I also have been thinking about, but it is not what > > I was referring to above. I think it would be good to keep the three > > cases (macvlan, VMDq, SR-IOV) as similar as possible from the user > > perspective, so using macvlan as an infrastructure for all of them > > sounds reasonable to me. > > Oh, so you'd basically do -net vt-d,if=eth0 and the rest would > automatically work? That's a pretty slick idea! I was only referring to how they get set up under the covers, e.g. creating the virtual device, configuring the MAC address etc, not the qemu side, but that would probably make sense as well. Or even better, qemu should probably not even know the difference between macvlan and VT-d. In both cases, it would open a macvtap file, but for VT-d adapters, the macvlan infrastructure can use hardware support, much in the way that VLAN tagging gets offloaded automatically to the hardware. Arnd <>< From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIpVA-0004Cy-Cv for qemu-devel@nongnu.org; Thu, 10 Dec 2009 15:20:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIpV5-00044b-5c for qemu-devel@nongnu.org; Thu, 10 Dec 2009 15:20:39 -0500 Received: from [199.232.76.173] (port=40567 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIpV5-00044C-0w for qemu-devel@nongnu.org; Thu, 10 Dec 2009 15:20:35 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:52008) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIpV2-0007gr-Hp for qemu-devel@nongnu.org; Thu, 10 Dec 2009 15:20:33 -0500 From: Arnd Bergmann Subject: Re: [Qemu-devel] Re: Guest bridge setup variations Date: Thu, 10 Dec 2009 20:20:26 +0000 References: <200912081707.42660.arnd@arndb.de> <200912101518.36128.arnd@arndb.de> <784CAF36-3F28-4FFD-82A2-0A4E54EDB831@suse.de> In-Reply-To: <784CAF36-3F28-4FFD-82A2-0A4E54EDB831@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912102020.26724.arnd@arndb.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "Fischer, Anna" , Alexander Graf , "virtualization@lists.linux-foundation.org" On Thursday 10 December 2009 19:14:28 Alexander Graf wrote: > > This is something I also have been thinking about, but it is not what > > I was referring to above. I think it would be good to keep the three > > cases (macvlan, VMDq, SR-IOV) as similar as possible from the user > > perspective, so using macvlan as an infrastructure for all of them > > sounds reasonable to me. > > Oh, so you'd basically do -net vt-d,if=eth0 and the rest would > automatically work? That's a pretty slick idea! I was only referring to how they get set up under the covers, e.g. creating the virtual device, configuring the MAC address etc, not the qemu side, but that would probably make sense as well. Or even better, qemu should probably not even know the difference between macvlan and VT-d. In both cases, it would open a macvtap file, but for VT-d adapters, the macvlan infrastructure can use hardware support, much in the way that VLAN tagging gets offloaded automatically to the hardware. Arnd <><