Message-ID: <500E9664.9030306@amd.com>
Date:	Tue, 24 Jul 2012 14:34:44 +0200
From:	Andre Przywara <andre.przywara@....com>
To:	Vladimir Davydov <vdavydov@...allels.com>
CC:	Borislav Petkov <bp@...64.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
	Borislav Petkov <borislav.petkov@....com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

On 07/24/2012 01:09 PM, Vladimir Davydov wrote:
> 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 have the new feature leaf at EAX=7. This contains things like BMI 
and AVX2 and probably more upcoming features.
So you may be safe for a while, but you need a solution in the long run.

>> 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.

So for this single kernel approach I'd understand it that way:
1. You boot up the kernel on the host, it should detect and enable all 
the features, say MCA.
2. After boot, you use /src/msr-tools/wrmsr to mask CPUID bits, again 
MCA for instance or AVX/AES or the like.
Since the (host side of the) kernel already detected it, this does not 
hurt the kernel features like MCA. But AVX will not be available to 
applications running in the "host container", which is probably OK since 
these are mostly management applications, right?
3. Then you start guests. The guest's libc will not detect the features 
because of the MSR masking. All you need now is /proc/cpuinfo filtering 
to make this bullet-proof, preferably through the container 
functionality. I see that you do already massive sysfs filtering and 
also /proc/<pid> filtering, so this maybe an option?

This approach does not need any kernel support (except for the 
/proc/cpuinfo filtering). Does this address the issues you have?

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists