On Wed, Jul 14, 2010 at 01:42:59PM -0700, Shreyas Bhatewara wrote:
> +/* vmkernel and device backend shared definitions */
> +
> +#define VMXNET3_PLUGIN_NAME_LEN 256
> +#define VMXNET3_PLUGIN_REPOSITORY "/usr/lib/vmware/npa_plugins"
Why would the kernel care about this file path? And since when
On Wed, Jul 14, 2010 at 10:18:22AM -0700, Pankaj Thakkar wrote:
> The plugin is guest agnostic and hence we did not want to rely on any
> kernel provided functions. The plugin uses only the interface provided
> by the shell.
Really? vmxnet3_plugin.c is no supposed to use any kernel-provided
funct
On 07/14/2010 10:54 AM, David Miller wrote:
> And doing what you're doing is foolish on so many levels. One more
> duplication of code, one more place for unnecessary bugs to live, one
> more place that might need optimizations and thus require duplication
> of even more work people have done over
From: Pankaj Thakkar
Date: Wed, 14 Jul 2010 10:18:22 -0700
> The plugin is guest agnostic and hence we did not want to rely on
> any kernel provided functions.
While I disagree entirely with this kind of approach, even that
doesn't justify what you're doing here.
memcpy() and memset() are on a
: Christoph Hellwig; Stephen Hemminger; Pankaj Thakkar;
pv-driv...@vmware.com; net...@vger.kernel.org; linux-ker...@vger.kernel.org;
virtualization@lists.linux-foundation.org
Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
Is there some reason that our in-kernel functions that
On Wed, 14 Jul 2010, Greg KH wrote:
> On Mon, Jul 12, 2010 at 08:06:28PM -0700, Shreyas Bhatewara wrote:
> > drivers/net/vmxnet3/vmxnet3_drv.c | 1845
> > +++--
>
> Your patch is line-wrapped and can not be applied :(
>
> Care to fix your email client?
>
> One
On Mon, Jul 12, 2010 at 08:06:28PM -0700, Shreyas Bhatewara wrote:
> drivers/net/vmxnet3/vmxnet3_drv.c | 1845
> +++--
Your patch is line-wrapped and can not be applied :(
Care to fix your email client?
One thing just jumped out at me when glancing at this:
> +st
On Mon, 12 Jul 2010 20:06:28 -0700
Shreyas Bhatewara wrote:
>
> On Thu, 2010-05-06 at 13:21 -0700, Christoph Hellwig wrote:
> > On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
> > > Let me put it bluntly. Any design that allows external code to run
> > > in the kernel is not g
On Mon, 12 Jul 2010 20:06:28 -0700
Shreyas Bhatewara wrote:
>
> On Thu, 2010-05-06 at 13:21 -0700, Christoph Hellwig wrote:
> > On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
> > > Let me put it bluntly. Any design that allows external code to run
> > > in the kernel is not g
On Thu, May 06, 2010 at 01:58:54AM -0700, Avi Kivity wrote:
> > 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?
No. This is a guideline which we
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
> Let me put it bluntly. Any design that allows external code to run
> in the kernel is not going to be accepted. Out of tree kernel modules are
> enough
> of a pain already, why do you expect the developers to add another
> inter
On Thu, May 06, 2010 at 11:04:11AM -0700, Pankaj Thakkar wrote:
> 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.
Which is simply not supportable for a cross-platform operatin
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote:
> > Forget about the licensing. Loading binary blobs written to a shim
> > layer is a complete pain in the ass and totally unsupportable, and
> > also uninteresting because of the overhead.
>
> [PT] Why do you think it is unsupportab
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
On 5/5/10 10:29 AM, "Dmitry Torokhov" 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
ot;net...@vger.kernel.org",
>> "virtualization@lists.linux-foundation.org"
>> ,
>> "pv-driv...@vmware.com",
>> Shreyas Bhatewara
>> Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
>>
>> On 05/05/
@vmware.com; Pankaj Thakkar;
> > net...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > virtualization@lists.linux-foundation.org
> > Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
> > vmxnet3
> >
> > On Wed, May 05, 2010 at 10:35:28AM -
l.org; virtualizat...@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" wrote:
>
> > It would not be a binary blob but software properly released u
l.org; virtualizat...@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" wrote:
>
> > It would not be a binary blob but software properly released u
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 dri
On Wednesday 05 May 2010 10:31:20 am Christoph Hellwig wrote:
> On Wed, May 05, 2010 at 10:29:40AM -0700, Dmitry Torokhov wrote:
> > > We're not going to add any kind of loader for binry blobs into kernel
> > > space, sorry. Don't even bother wasting your time on this.
> >
> > It would not be a b
On Wednesday 05 May 2010 10:23:16 am Christoph Hellwig wrote:
> On Tue, May 04, 2010 at 04:02:25PM -0700, Pankaj Thakkar wrote:
> > The plugin image is provided by the IHVs along with the PF driver and is
> > packaged in the hypervisor. The plugin image is OS agnostic and can be
> > loaded either i
l.org;
> linux-ker...@vger.kernel.org; virtualizat...@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:
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 thro
On Wednesday 05 May 2010 19:47:10 Pankaj Thakkar wrote:
> >
> > Forget about the licensing. Loading binary blobs written to a shim
> > layer is a complete pain in the ass and totally unsupportable, and
> > also uninteresting because of the overhead.
>
> [PT] Why do you think it is unsupportable?
linux-foundation.org"
> ,
> "pv-driv...@vmware.com" ,
> Shreyas Bhatewara
> 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
linux-foundation.org"
> ,
> "pv-driv...@vmware.com" ,
> Shreyas Bhatewara ,
> "k...@vger.kernel.org"
> Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
>
> * Pankaj Thakkar (pthak...@vmware.com) wrote:
> > We intend to
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 whi
On Wed, 5 May 2010 13:39:51 -0400
Christoph Hellwig wrote:
> On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
> > Yes, with the exception that the only body of code that will be
> > accepted by the shell should be GPL-licensed and thus open and available
> > for examining. This is
alization@lists.linux-foundation.org
> Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
> vmxnet3
>
> On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
> > Yes, with the exception that the only body of code that will be
> > accepted by the s
On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
> Yes, with the exception that the only body of code that will be
> accepted by the shell should be GPL-licensed and thus open and available
> for examining. This is not different from having a standard kernel
> module that is loaded
On Wed, May 05, 2010 at 10:29:40AM -0700, Dmitry Torokhov wrote:
> > We're not going to add any kind of loader for binry blobs into kernel
> > space, sorry. Don't even bother wasting your time on this.
> >
>
> It would not be a binary blob but software properly released under GPL.
> The current
On Tue, May 04, 2010 at 04:02:25PM -0700, Pankaj Thakkar wrote:
> The plugin image is provided by the IHVs along with the PF driver and is
> packaged in the hypervisor. The plugin image is OS agnostic and can be loaded
> either into a Linux VM or a Windows VM. The plugin is written against the
> S
t;pv-driv...@vmware.com" ,
> Shreyas Bhatewara
> Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
>
> From: Pankaj Thakkar
> Date: Tue, 4 May 2010 17:18:57 -0700
>
> > The purpose of this email is to introduce the architecture and the
> > desig
"pv-driv...@vmware.com" ,
> Shreyas Bhatewara
> Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
>
> On Tue, 4 May 2010 16:02:25 -0700
> Pankaj Thakkar wrote:
>
> > Device passthrough technology allows a guest to bypass the hypervisor and
Device passthrough technology allows a guest to bypass the hypervisor and drive
the underlying physical device. VMware has been exploring various ways to
deliver this technology to users in a manner which is easy to adopt. In this
process we have prepared an architecture along with Intel - NPA (Net
On Tue, 4 May 2010 17:18:57 -0700
Pankaj Thakkar wrote:
> The purpose of this email is to introduce the architecture and the design
> principles. The overall project involves more than just changes to vmxnet3
> driver and hence we though an overview email would be better. Once people
> agree t
* Pankaj Thakkar (pthak...@vmware.com) wrote:
> We intend to upgrade the upstreamed vmxnet3 driver to implement NPA so that
> Linux users can exploit the benefits provided by passthrough devices in a
> seamless manner while retaining the benefits of virtualization. The document
> below tries to ans
From: Pankaj Thakkar
Date: Tue, 4 May 2010 17:18:57 -0700
> The purpose of this email is to introduce the architecture and the
> design principles. The overall project involves more than just
> changes to vmxnet3 driver and hence we though an overview email
> would be better. Once people agree to
On Tue, 4 May 2010 16:02:25 -0700
Pankaj Thakkar wrote:
> Device passthrough technology allows a guest to bypass the hypervisor and
> drive
> the underlying physical device. VMware has been exploring various ways to
> deliver this technology to users in a manner which is easy to adopt. In this
>
40 matches
Mail list logo
