From: Alok Kataria <akataria@vmware.com>
To: Jaswinder Singh Rajput <jaswinder@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
x86 maintainers <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip] x86: move vmware to hypervisor
Date: Wed, 25 Mar 2009 10:24:13 -0700 [thread overview]
Message-ID: <1238001853.32497.22.camel@alok-dev1> (raw)
In-Reply-To: <1238000840.2500.49.camel@ht.satnam>
On Wed, 2009-03-25 at 10:07 -0700, Jaswinder Singh Rajput wrote:
> On Wed, 2009-03-25 at 09:52 -0700, Alok Kataria wrote:
> > >
> > > vmware can be considered a CPU here, so i think making the disabling
> > > also depend on PROCESSOR_SELECT.
> >
> > Ingo, this code is not just to be used by VMware, the reason we did this
> > generically was so that a guest could run unaltered on *any* fully
> > virtualized hypervisor.
> > And give that this code is just a boot setup thing, the only thing this
> > patch saves over here is not running the detection code on native
> > systems. All the rest of the code is guarded by the
> > "boot_cpu_data.x86_hyper_vendor" checks anyways.
> >
> > I don't really see the point of adding one more config option just for
> > this.
> >
>
> Can you please explain what is the point of adding this support all the
> time if this is useless for 99.9% of cases. IMHO, it should be optional.
First of all, I don't know how did you get to the 99.9% number, though I
think its not a point worth debating, just like to share some info with
you. More and more people are adopting virtualization now a days and
give the trend i don't see just 0.1% people running Linux on virtualized
hardware. So though its not a common case there is still a large user
base.
I am not saying we should not hide this behind a config at all. The
point is there is nothing that we save by adding a new config, so what's
the point at all. If you can give me a solid reason like, say, you save
1% code space with this config option, or 'n' sec in the boottime, I am
all ears for such an argument.
Thanks,
Alok
>
> --
> JSR
>
>
>
>
>
next prev parent reply other threads:[~2009-03-25 17:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 9:19 [PATCH -tip] x86: move vmware to hypervisor Jaswinder Singh Rajput
2009-03-17 9:39 ` Ingo Molnar
2009-03-17 9:48 ` Jaswinder Singh Rajput
2009-03-17 15:50 ` H. Peter Anvin
2009-03-25 5:29 ` Jaswinder Singh Rajput
2009-03-25 12:59 ` Ingo Molnar
2009-03-25 16:52 ` Alok Kataria
2009-03-25 17:07 ` Jaswinder Singh Rajput
2009-03-25 17:24 ` Alok Kataria [this message]
2009-03-25 17:38 ` Jaswinder Singh Rajput
2009-03-25 18:18 ` Alok Kataria
2009-03-26 7:10 ` david
2009-03-26 16:40 ` Alok Kataria
2009-03-27 0:10 ` H. Peter Anvin
2009-03-25 13:38 ` Mark Lord
2009-03-17 17:28 ` Alok Kataria
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1238001853.32497.22.camel@alok-dev1 \
--to=akataria@vmware.com \
--cc=hpa@zytor.com \
--cc=jaswinder@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.