On Thu, 2009-10-01 at 20:00 -0700, Eric W. Biederman wrote:
> >> btw the "default" in KConfig tends to be totally ignored by distro
> >> kernel maintainers... please don't assume that just because some default
> >> is set in KConfig it has ANY impact on what shows up in distributions.
> >
> > So,
Alok Kataria writes:
> On Tue, 2009-09-29 at 01:08 -0700, Arjan van de Ven wrote:
>> > For now I have just added some text in the feature-removal file and
>> > disabled VMI by default in the Kconfig, the reason that needs to be
>> > done is because "Live Migration" of a VMI enabled VM to future
>
* Alok Kataria (akata...@vmware.com) wrote:
> Mark VMI for removal in feature-removal-schedule.txt.
>
> From: Alok N Kataria
>
> Add text in feature-removal.txt and also modify Kconfig to disable
> vmi by default.
>
> Signed-off-by: Alok N Kataria
Acked-by: Chris Wright
_
On 09/29/2009 10:25 AM, Alok Kataria wrote:
> diff --git a/arch/x86/kernel/vmi_32.c b/arch/x86/kernel/vmi_32.c
> index 31e6f6c..d430e4c 100644
> --- a/arch/x86/kernel/vmi_32.c
> +++ b/arch/x86/kernel/vmi_32.c
> @@ -648,7 +648,7 @@ static inline int __init activate_vmi(void)
>
> pv_info.para
On Tue, 2009-09-29 at 02:01 -0700, Chris Wright wrote:
> * Alok Kataria (akata...@vmware.com) wrote:
> >
> > On Mon, 2009-09-28 at 19:25 -0700, H. Peter Anvin wrote:
> > > On 09/28/2009 05:45 PM, Alok Kataria wrote:
> > > > + bool "VMI Guest support [will be deprecated soon]"
> > > > +
On 09/29/2009 09:49 AM, Alok Kataria wrote:
>
> So, are you saying that we should be doing something else along with
> toggling it off in the Kconfig ?
> We have already informed most of the distro folks about this deprecation
> so I think we should be okay there, but if there is something else t
On Tue, 2009-09-29 at 10:27 -0700, H. Peter Anvin wrote:
> On 09/29/2009 10:25 AM, Alok Kataria wrote:
> > diff --git a/arch/x86/kernel/vmi_32.c b/arch/x86/kernel/vmi_32.c
> > index 31e6f6c..d430e4c 100644
> > --- a/arch/x86/kernel/vmi_32.c
> > +++ b/arch/x86/kernel/vmi_32.c
> > @@ -648,7 +648,7 @
On Tue, 2009-09-29 at 01:08 -0700, Arjan van de Ven wrote:
> > For now I have just added some text in the feature-removal file and
> > disabled VMI by default in the Kconfig, the reason that needs to be
> > done is because "Live Migration" of a VMI enabled VM to future
> > products which don't sup
* Alok Kataria (akata...@vmware.com) wrote:
>
> On Mon, 2009-09-28 at 19:25 -0700, H. Peter Anvin wrote:
> > On 09/28/2009 05:45 PM, Alok Kataria wrote:
> > > + bool "VMI Guest support [will be deprecated soon]"
> > > + default n
> >
> > This is incorrect use of the word "deprecated"... it's *alr
> For now I have just added some text in the feature-removal file and
> disabled VMI by default in the Kconfig, the reason that needs to be
> done is because "Live Migration" of a VMI enabled VM to future
> products which don't support VMI will not work, so its important that
> newer distros keep t
On Mon, 2009-09-28 at 19:25 -0700, H. Peter Anvin wrote:
> On 09/28/2009 05:45 PM, Alok Kataria wrote:
> > + bool "VMI Guest support [will be deprecated soon]"
> > + default n
>
> This is incorrect use of the word "deprecated"... it's *already*
> deprecated (a word which pretty much means the
On 09/28/2009 05:45 PM, Alok Kataria wrote:
> + bool "VMI Guest support [will be deprecated soon]"
> + default n
This is incorrect use of the word "deprecated"... it's *already*
deprecated (a word which pretty much means the opposite of "recommended".)
As far as "default n" is concerned..
On Wed, 2009-09-23 at 00:29 -0700, Gerd Hoffmann wrote:
> On 09/22/09 21:30, Alok Kataria wrote:
> > Hi Ingo,
> >
> > On Sun, 2009-09-20 at 00:42 -0700, Ingo Molnar wrote:
> >
> >>
> >> The thing is, the overwhelming majority of vmware users dont benefit
> >> from hardware features like nested pag
On 09/22/09 21:30, Alok Kataria wrote:
> Hi Ingo,
>
> On Sun, 2009-09-20 at 00:42 -0700, Ingo Molnar wrote:
>
>>
>> The thing is, the overwhelming majority of vmware users dont benefit
>> from hardware features like nested page tables yet. So this needs to be
>> done _way_ more carefully, with a pr
Alok Kataria wrote:
>
> What do you suggest would be the right time ?
>
> Please note that the next major release of VMware's product will not
> have this supported. Also that, most of our customers will actually be
> running some distro's enterprise release, rather than running the
> cutting ed
On Tue, 2009-09-22 at 14:27 -0700, H. Peter Anvin wrote:
> Alok Kataria wrote:
> > Hi Ingo,
> >
> > On Sun, 2009-09-20 at 00:42 -0700, Ingo Molnar wrote:
> >
> >> The thing is, the overwhelming majority of vmware users dont benefit
> >> from hardware features like nested page tables yet. So thi
Alok Kataria wrote:
> Hi Ingo,
>
> On Sun, 2009-09-20 at 00:42 -0700, Ingo Molnar wrote:
>
>> The thing is, the overwhelming majority of vmware users dont benefit
>> from hardware features like nested page tables yet. So this needs to be
>> done _way_ more carefully, with a proper sunset period
On 09/22/09 12:30, Alok Kataria wrote:
> We can certainly look at removing some paravirt-hooks which are only
> used by VMI. Not sure if there are any but will take a look when we
> actually remove VMI.
>
There are a couple:
* pte_update_defer
* alloc_pmd_clone
lguest appears to still
Hi Ingo,
On Sun, 2009-09-20 at 00:42 -0700, Ingo Molnar wrote:
>
> The thing is, the overwhelming majority of vmware users dont benefit
> from hardware features like nested page tables yet. So this needs to be
> done _way_ more carefully, with a proper sunset period of a couple of
> kernel cy
On 09/22/09 12:04, Ingo Molnar wrote:
> Sorry for being dense, but what does that mean precisely? No available
> hardware? Xen doesnt run?
Nobody has implemented hybrid PV mode yet, so we haven't got anything to
measure.
Also, I don't think there have been very many measurements of Linux HVM
(fu
* Jeremy Fitzhardinge wrote:
> On 09/22/09 11:02, Ingo Molnar wrote:
>
> > obviously they are workload dependent - that's why numbers were
> > posted in this thread with various workloads. Do you concur with
> > those conclusions that they are generally a speedup over paravirt?
> > If not, wh
On 09/22/09 11:02, Ingo Molnar wrote:
> obviously they are workload dependent - that's why numbers were posted
> in this thread with various workloads. Do you concur with those
> conclusions that they are generally a speedup over paravirt? If not,
> which are the workloads where paravirt offers
* Jeremy Fitzhardinge wrote:
> On 09/22/09 01:09, Ingo Molnar wrote:
> >>> kvm will be removing the pvmmu support soon; and Xen is talking about
> >>> running paravirtualized guests in a vmx/svm container where they don't
> >>> need most of the hooks.
> >>>
> >> We have no plans to drop s
On 09/22/09 00:22, Rusty Russell wrote:
> When they're all gone, even I don't think lguest is sufficient excuse
> to keep CONFIG_PARAVIRT. Oh well. But that will probably be a while.
>
/Solidarność/!
J
___
Virtualization mailing list
Virtualiza
On 09/22/09 01:09, Ingo Molnar wrote:
>>> kvm will be removing the pvmmu support soon; and Xen is talking about
>>> running paravirtualized guests in a vmx/svm container where they don't
>>> need most of the hooks.
>>>
>> We have no plans to drop support for non-vmx/svm capable processors,
* Jeremy Fitzhardinge wrote:
> On 09/20/09 02:00, Avi Kivity wrote:
> > On 09/20/2009 10:52 AM, Arjan van de Ven wrote:
> >> On Sun, 20 Sep 2009 09:42:47 +0200
> >> Ingo Molnar wrote:
> >>
> >>
> >>> If we were able to rip out all (or most) of paravirt from arch/x86 it
> >>> would be temptin
On Sun, 20 Sep 2009 06:30:21 pm Avi Kivity wrote:
> On 09/20/2009 10:52 AM, Arjan van de Ven wrote:
> > On Sun, 20 Sep 2009 09:42:47 +0200
> > Ingo Molnar wrote:
> >
> >
> >> If we were able to rip out all (or most) of paravirt from arch/x86 it
> >> would be tempting for other technical reason
On Sun, 20 Sep 2009 09:42:47 +0200
Ingo Molnar wrote:
> If we were able to rip out all (or most) of paravirt from arch/x86 it
> would be tempting for other technical reasons - but the patch above
> is well localized.
interesting question is if this would allow us to remove a few of the
paravirt
On 09/20/2009 06:49 PM, Jeremy Fitzhardinge wrote:
>> kvm will be removing the pvmmu support soon; and Xen is talking about
>> running paravirtualized guests in a vmx/svm container where they don't
>> need most of the hooks.
>>
>>
> We have no plans to drop support for non-vmx/svm capable pro
On 09/20/09 02:00, Avi Kivity wrote:
> On 09/20/2009 10:52 AM, Arjan van de Ven wrote:
>> On Sun, 20 Sep 2009 09:42:47 +0200
>> Ingo Molnar wrote:
>>
>>
>>> If we were able to rip out all (or most) of paravirt from arch/x86 it
>>> would be tempting for other technical reasons - but the patch ab
On 09/20/2009 10:52 AM, Arjan van de Ven wrote:
> On Sun, 20 Sep 2009 09:42:47 +0200
> Ingo Molnar wrote:
>
>
>> If we were able to rip out all (or most) of paravirt from arch/x86 it
>> would be tempting for other technical reasons - but the patch above
>> is well localized.
>>
> interes
* Alok Kataria wrote:
> Here is the patch which actually removes the vmi code.
>
> Signed-off-by: Alok N Kataria
> ---
>
> Documentation/kernel-parameters.txt |2
> arch/x86/Kconfig| 10
> arch/x86/include/asm/vmi.h | 269 --
> arch/x86/include/a
Here is the patch which actually removes the vmi code.
Signed-off-by: Alok N Kataria
---
Documentation/kernel-parameters.txt |2
arch/x86/Kconfig| 10
arch/x86/include/asm/vmi.h | 269 --
arch/x86/include/asm/vmi_time.h | 98
arch/x86/ker
On Sat, 2009-09-19 at 15:44 -0700, Greg KH wrote:
> On Thu, Sep 17, 2009 at 05:17:08PM -0700, Alok Kataria wrote:
> > Given this new development, I wanted to discuss how should we go about
> > retiring the VMI code from mainline Linux, i.e. the vmi_32.c and
> > vmiclock_32.c bits.
> >
> > One of
On 09/19/09 15:44, Greg KH wrote:
> That sounds good to me, how intrusive are the patches to do this? Is it
> going to be tricky to get everything merged properly in -tip for it?
They should be very local - just a matter of removing a couple of files
and dropping some config options.
J
_
On Thu, Sep 17, 2009 at 05:17:08PM -0700, Alok Kataria wrote:
> Given this new development, I wanted to discuss how should we go about
> retiring the VMI code from mainline Linux, i.e. the vmi_32.c and
> vmiclock_32.c bits.
>
> One of the options that I am contemplating is to drop the code from th
On 09/18/2009 03:17 AM, Alok Kataria wrote:
> Hi,
>
> We ran a few experiments to compare performance of VMware's
> paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)
> on VMware's hypervisor.
>
> To give some background, VMI is VMware's paravirtualization
> specification whic
On Thu, 2009-09-17 at 17:58 -0700, Chris Wright wrote:
> * Jeremy Fitzhardinge (jer...@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 l
* Jeremy Fitzhardinge (jer...@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
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 o
* Alok Kataria (akata...@vmware.com) wrote:
> We ran a few experiments to compare performance of VMware's
> paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)
> on VMware's hypervisor.
>
> To give some background, VMI is VMware's paravirtualization
> specification which tries
Hi,
We ran a few experiments to compare performance of VMware's
paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)
on VMware's hypervisor.
To give some background, VMI is VMware's paravirtualization
specification which tries to optimize CPU and MMU operations of the
guest op
42 matches
Mail list logo
