Re: Paravirtualization on VMware's Platform [VMI].

[Alok Kataria <akataria@vmware.com>]

On Thu, 2009-09-17 at 17:58 -0700, Chris Wright wrote:
> * Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> > On 09/17/09 17:34, Chris Wright wrote:
> > >> One of the options that I am contemplating is to drop the code from the
> > >> tip tree in this release cycle, and given that this should be a low risk
> > >> change we can remove it from Linus's tree later in the merge cycle.
> > >>
> > >> Let me know your views on this or if you think we should do this some
> > >> other way.
> > >>     
> > > Typically we give time measured in multiple release cycles
> > > before deprecating a feature.  This means placing an entry in
> > > Documentation/feature-removal-schedule.txt, and potentially
> > > adding some noise to warn users they are using a deprecated
> > > feature.
> > 
> > That's true if the feature has some functional effect on users.  But at
> > first sight, VMI is really just an optimisation, and a non-VMI-equipped
> > kernel would be completely functionally equivalent, right?
> 
> True.  I'm all for removing code that's got no planned maintenance and
> no place to run ;-)

That's correct, Jeremy put it as well as I could, VMI was always a
optimization, and we expect that new HW features bridge that performance
gap too. So a generic kernel will run just as well on VMware's platform.

Having said that, I would like to clarify that existing products which
support VMI will still carry on supporting it for the current customer
base. Its only the new products which will stop supporting this feature.

> 
> > On the other hand, there could well be a performance regression which
> > could affect users.  However they're taking the explicit step of
> > withdrawing support for VMI, so I guess they can just take that in their
> > stride.
> 
> Yeah.  Different than normal deprecation since it's atop VMware's HV
> which is all in their domain.

Yep that's true. 

Thanks,
Alok