RFC: Network Plugin Architecture (NPA) for vmxnet3
in [Kernel]
|
From: Shreyas Bhatewara on 5 May 2010 18:10 > -----Original Message----- > From: pv-drivers-bounces(a)vmware.com [mailto:pv-drivers- > bounces(a)vmware.com] On Behalf Of Arnd Bergmann > Sent: Wednesday, May 05, 2010 2:53 PM > To: Dmitry Torokhov > Cc: Christoph Hellwig; pv-drivers(a)vmware.com; netdev(a)vger.kernel.org; > linux-kernel(a)vger.kernel.org; virtualization(a)lists.linux- > foundation.org; Pankaj Thakkar > Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for > vmxnet3 > > On Wednesday 05 May 2010 22:36:31 Dmitry Torokhov wrote: > > > > On Wednesday 05 May 2010 01:09:48 pm Arnd Bergmann wrote: > > > > > If you have any interesting in developing this further, do: > > > > > > > > > > (1) move the limited VF drivers directly into the kernel tree, > > > > > talk to them through a normal ops vector > > > > > > > > [PT] This assumes that all the VF drivers would always be > available. > > > > Also we have to support windows and our current design supports > it > > > > nicely in an OS agnostic manner. > > > > > > Your approach assumes that the plugin is always available, which > has > > > exactly the same implications. > > > > Since plugin[s] are carried by the host they are indeed always > > available. > > But what makes you think that you can build code that can be linked > into arbitrary future kernel versions? The kernel does not define any > calling conventions that are stable across multiple versions or > configurations. For example, you'd have to provide different binaries > for each combination of The plugin image is not linked against Linux kernel. It is OS agnostic infact (Eg. same plugin works for Linux and Windows VMs) Plugin is built against the shell API interface. It is loaded by hypervisor in a set of pages provided by shell. Guest OS specific tasks (like allocation of pages for plugin to load) are handled by shell and this is the one which will be upstreamed in Linux kernel. Maintenance of shell is the same as for any other driver currently existing in Linux kernel. ->Shreyas > > - 32/64 bit code > - gcc -mregparm=? > - lockdep > - tracepoints > - stackcheck > - NOMMU > - highmem > - whatever new gets merged > > If you build the plugins only for specific versions of "enterprise" > Linux > kernels, the code becomes really hard to debug and maintain. > If you wrap everything in your own version of the existing interfaces, > your > code gets bloated to the point of being unmaintainable. > > So I have to correct myself: this is very different from assuming the > driver is available in the guest, it's actually much worse. > > Arnd > _______________________________________________ > Pv-drivers mailing list > Pv-drivers(a)vmware.com > http://mailman2.vmware.com/mailman/listinfo/pv-drivers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Scott Feldman on 5 May 2010 22:10 On 5/5/10 10:29 AM, "Dmitry Torokhov" <dtor(a)vmware.com> wrote: > It would not be a binary blob but software properly released under GPL. > The current plan is for the shell to enforce GPL requirement on the > plugin code, similar to what module loaded does for regular kernel > modules. On 5/5/10 3:05 PM, "Shreyas Bhatewara" <sbhatewara(a)vmware.com> wrote: > The plugin image is not linked against Linux kernel. It is OS agnostic infact > (Eg. same plugin works for Linux and Windows VMs) Are there any issues with injecting the GPL-licensed plug-in into the Windows vmxnet3 NDIS driver? -scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Shreyas Bhatewara on 6 May 2010 03:30 > -----Original Message----- > From: Scott Feldman [mailto:scofeldm(a)cisco.com] > Sent: Wednesday, May 05, 2010 7:04 PM > To: Shreyas Bhatewara; Arnd Bergmann; Dmitry Torokhov > Cc: Christoph Hellwig; pv-drivers(a)vmware.com; netdev(a)vger.kernel.org; > linux-kernel(a)vger.kernel.org; virtualization(a)lists.linux- > foundation.org; Pankaj Thakkar > Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for > vmxnet3 > > On 5/5/10 10:29 AM, "Dmitry Torokhov" <dtor(a)vmware.com> wrote: > > > It would not be a binary blob but software properly released under > GPL. > > The current plan is for the shell to enforce GPL requirement on the > > plugin code, similar to what module loaded does for regular kernel > > modules. > > On 5/5/10 3:05 PM, "Shreyas Bhatewara" <sbhatewara(a)vmware.com> wrote: > > > The plugin image is not linked against Linux kernel. It is OS > agnostic infact > > (Eg. same plugin works for Linux and Windows VMs) > > Are there any issues with injecting the GPL-licensed plug-in into the > Windows vmxnet3 NDIS driver? > > -scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 6 May 2010 05:00 On 05/05/2010 10:44 PM, Pankaj Thakkar wrote: > On Wed, May 05, 2010 at 10:59:51AM -0700, Avi Kivity wrote: > >> Date: Wed, 5 May 2010 10:59:51 -0700 >> From: Avi Kivity<avi(a)redhat.com> >> To: Pankaj Thakkar<pthakkar(a)vmware.com> >> CC: "linux-kernel(a)vger.kernel.org"<linux-kernel(a)vger.kernel.org>, >> "netdev(a)vger.kernel.org"<netdev(a)vger.kernel.org>, >> "virtualization(a)lists.linux-foundation.org" >> <virtualization(a)lists.linux-foundation.org>, >> "pv-drivers(a)vmware.com"<pv-drivers(a)vmware.com>, >> Shreyas Bhatewara<sbhatewara(a)vmware.com> >> Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3 >> >> On 05/05/2010 02:02 AM, Pankaj Thakkar wrote: >> >>> 2. Hypervisor control: All control operations from the guest such as programming >>> MAC address go through the hypervisor layer and hence can be subjected to >>> hypervisor policies. The PF driver can be further used to put policy decisions >>> like which VLAN the guest should be on. >>> >>> >> Is this enforced? Since you pass the hardware through, you can't rely >> on the guest actually doing this, yes? >> > We don't pass the whole VF to the guest. Only the BAR which is responsible for > TX/RX/intr is mapped into guest space. Does the SR/IOV spec guarantee that you will have such a separation? > >> >>> We have reworked our existing Linux vmxnet3 driver to accomodate NPA by >>> splitting the driver into two parts: Shell and Plugin. The new split driver is >>> >>> >> So the Shell would be the reworked or new bond driver, and Plugins would >> be ordinary Linux network drivers. >> > In NPA we do not rely on the guest OS to provide any of these services like > bonding or PCI hotplug. Well the Shell does some sort of bonding (there are two links and the shell selects which one to exercise) and some sort of hotplug. Since the Shell is part of the guest OS, you do rely on it. It's certainly simpler than PCI hotplug or ordinary bonding. > We don't rely on the guest OS to unmap a VF and switch > a VM out of passthrough. In a bonding approach that becomes an issue you can't > just yank a device from underneath, you have to wait for the OS to process the > request and switch from using VF to the emulated device and this makes the > hypervisor dependent on the guest OS. How can you unmap the VF without guest cooperation? If you're executing Plugin code, you can't yank anything out. Are plugins executed with preemption/interrupts disabled? > Also we don't rely on the presence of all > the drivers inside the guest OS (be it Linux or Windows), the ESX hypervisor > carries all the plugins and the PF drivers and injects the right one as needed. > These plugins are guest agnostic and the IHVs do not have to write plugins for > different OS. > What ISAs do those plugins support? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pankaj Thakkar on 6 May 2010 14:10 On Thu, May 06, 2010 at 01:19:33AM -0700, Gleb Natapov wrote: > Overhead of interpreting bytecode plugin is written in. Or are you > saying plugin is x86 assembly (32bit or 64bit btw?) and other arches > will have to have in kernel x86 emulator to use the plugin (like some > of them had for vgabios)? > Plugin is x86 or x64 machine code. You write the plugin in C and compile it using gcc/ld to get the object file, we map the relevant sections only to the OS space. NPA is a way of enabling passthrough of SR-IOV NICs with live migration support on ESX Hypervisor which runs only on x86/x64 hardware. It only supports x86/x64 guest OS. So we don't have to worry about other architectures. If NPA approach needs to be extended and adopted by other hypervisors then we have to take care of that. Today we have two plugins images per VF (one for 32-bit, one for 64-bit). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [GIT PULL] ocfs2 fixes for 2.6.34-rc Next: Exposing TSC "reliability" to userland |