public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Borislav Petkov <bp@amd64.org>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <ak@linux.intel.com>,
	Borislav Petkov <borislav.petkov@amd.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features
Date: Tue, 24 Jul 2012 15:09:52 +0400	[thread overview]
Message-ID: <500E8280.6050905@parallels.com> (raw)
In-Reply-To: <20120724101041.GA24739@aftab.osrc.amd.com>

On 07/24/2012 02:10 PM, Borislav Petkov wrote:
> On Tue, Jul 24, 2012 at 12:29:19PM +0400, Vladimir Davydov wrote:
>> I guess that when the more advanced features become widely-used,
>> vendors will offer new MSRs and/or CPUID faulting.
> And this right there is the dealbreaker:
>
> So what are you doing for cpus which have the advanced CPUID features
> leafs but there are no MSRs to turn those bits off?

We have not encountered this situation in our environments and I hope we 
won't :-)

But look, these CPUID functions cover majority of CPU features, don't 
they? So, most of "normal" apps inside VM will survive migration. 
Perhaps, some low-level utils won't. I guess that's why there are no 
MSRs for other levels provided by vendors.

> You surely need some software-only solution for the migration to work,
> no?

Yes.

> If so, why not apply that solution to your hypervisor without touching
> the kernel at all?

In most hypervisor-based virtualization products, this is already 
implemented using VMM-exits, so that each VM can have arbitrary CPUID 
mask set by the admin.

The problem is that we have no hypervisor. "Virtualization" we want this 
feature for is based on cgroups and namespaces (examples are OpenVZ and 
mainstream LXC). Tasks are just grouped into virtual environments and 
share the same kernel, which is proved to be more memory usage efficient 
than traditional hypervisor-based approaches.

> Thanks.
>


  reply	other threads:[~2012-07-24 11:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-20 16:37 [PATCH 1/2] cpu: common: make clearcpuid option take bits list Vladimir Davydov
2012-07-20 16:37 ` [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features Vladimir Davydov
2012-07-20 17:10   ` Andi Kleen
2012-07-20 17:18     ` H. Peter Anvin
2012-07-25 11:51     ` Vladimir Davydov
2012-07-20 17:20   ` H. Peter Anvin
2012-07-20 18:21     ` Vladimir Davydov
2012-07-20 20:19       ` H. Peter Anvin
2012-07-20 20:37         ` Vladimir Davydov
2012-07-21 10:37   ` Borislav Petkov
2012-07-24  7:06     ` Vladimir Davydov
2012-07-24  7:48       ` Borislav Petkov
2012-07-24  8:14       ` Andre Przywara
2012-07-24  8:29         ` Vladimir Davydov
2012-07-24 10:10           ` Borislav Petkov
2012-07-24 11:09             ` Vladimir Davydov [this message]
2012-07-24 12:34               ` Andre Przywara
2012-07-24 12:44                 ` Alan Cox
2012-07-25 10:31                   ` Vladimir Davydov
2012-07-25 10:58                     ` Andre Przywara
2012-07-25 11:02                       ` Vladimir Davydov
2012-07-25 11:17                         ` Andre Przywara
2012-07-25 11:43                           ` Vladimir Davydov
2012-07-25 11:31                     ` Alan Cox
2012-07-25 11:46                       ` Vladimir Davydov
2012-07-25 10:31                 ` Vladimir Davydov
2012-07-25 10:43                   ` Borislav Petkov
2012-07-25 11:39                     ` Vladimir Davydov
2012-07-25  0:57               ` H. Peter Anvin
2012-07-25  6:58                 ` Vladimir Davydov
2012-07-25 14:13                   ` H. Peter Anvin
2012-07-25 11:49                 ` Vladimir Davydov
2012-07-24  9:50         ` Borislav Petkov
2012-07-24 10:32           ` Alan Cox
2012-07-24 11:04             ` Borislav Petkov

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=500E8280.6050905@parallels.com \
    --to=vdavydov@parallels.com \
    --cc=ak@linux.intel.com \
    --cc=andre.przywara@amd.com \
    --cc=andreas.herrmann3@amd.com \
    --cc=borislav.petkov@amd.com \
    --cc=bp@amd64.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox