With the necessary infrastructure, yes. Trap and emulate is montrivial work.
Vladimir Davydov wrote:
>On 07/25/2012 04:57 AM, H. Peter Anvin wrote:
>> On 07/24/2012 04:09 AM, Vladimir Davydov wrote:
>>> We have not encountered this situation in our environments and I
>hope we
>>> won't :-)
>>>
On 07/20/2012 09:10 PM, Andi Kleen wrote:
+ unsigned int *msr_ext_cpuid_mask)
+{
+ unsigned int msr, msr_ext;
+
+ msr = msr_ext = 0;
+
+ switch (c->x86_model) {
You have to check the family too.
+
+ return msr;
+}
+
+static void __c
On 07/25/2012 04:57 AM, H. Peter Anvin wrote:
On 07/24/2012 04:09 AM, Vladimir Davydov wrote:
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 s
On 07/25/2012 03:31 PM, Alan Cox wrote:
On Wed, 25 Jul 2012 14:31:30 +0400
Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the issues you have?
You can do the /proc/cpui
On 07/25/2012 03:17 PM, Andre Przywara wrote:
On 07/25/2012 01:02 PM, Vladimir Davydov wrote:
On 07/25/2012 02:58 PM, Andre Przywara wrote:
On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/p
On 07/25/2012 02:43 PM, Borislav Petkov wrote:
On Wed, Jul 25, 2012 at 02:31:23PM +0400, Vladimir Davydov wrote:
So, you prefer adding some filtering of /proc/cpuinfo into the
mainstream kernel
That's already there right? And your 1/2 patch was making toggling those
bits easier.
(not now, lat
On Wed, 25 Jul 2012 14:31:30 +0400
Vladimir Davydov wrote:
> On 07/24/2012 04:44 PM, Alan Cox wrote:
> >> This approach does not need any kernel support (except for the
> >> /proc/cpuinfo filtering). Does this address the issues you have?
> > You can do the /proc/cpuinfo filtering in user space t
On 07/25/2012 01:02 PM, Vladimir Davydov wrote:
On 07/25/2012 02:58 PM, Andre Przywara wrote:
On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the i
On 07/25/2012 02:58 PM, Andre Przywara wrote:
On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the issues you have?
You can do the /proc/cpuinfo fil
On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the issues you have?
You can do the /proc/cpuinfo filtering in user space too
How?
I wanted to
On Wed, Jul 25, 2012 at 02:31:23PM +0400, Vladimir Davydov wrote:
> So, you prefer adding some filtering of /proc/cpuinfo into the
> mainstream kernel
That's already there right? And your 1/2 patch was making toggling those
bits easier.
> (not now, later, for LXC to work) instead of enabling clea
On 07/24/2012 04:44 PM, Alan Cox wrote:
This approach does not need any kernel support (except for the
/proc/cpuinfo filtering). Does this address the issues you have?
You can do the /proc/cpuinfo filtering in user space too
How?
--
To unsubscribe from this list: send the line "unsubscribe li
On 07/24/2012 04:34 PM, Andre Przywara wrote:
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
On 07/25/2012 04:57 AM, H. Peter Anvin wrote:
On 07/24/2012 04:09 AM, Vladimir Davydov wrote:
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 s
On 07/24/2012 04:09 AM, Vladimir Davydov wrote:
>
> 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 lo
> This approach does not need any kernel support (except for the
> /proc/cpuinfo filtering). Does this address the issues you have?
You can do the /proc/cpuinfo filtering in user space too
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
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 th
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 fo
On Tue, Jul 24, 2012 at 11:32:04AM +0100, Alan Cox wrote:
> > So actually, making it straightforward to disable CPUID feature bits
> > just for every whim is the bug.
>
> Sometimes its needed to make stuff work. Expecting user space to go
> digging in odd places
Nah, not odd places. Simply doing
> So actually, making it straightforward to disable CPUID feature bits
> just for every whim is the bug.
Sometimes its needed to make stuff work. Expecting user space to go
digging in odd places isn't good either but exposing *both* true/apparent
cpuid bits might not be a bad idea.
> I'd like to
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
On Tue, Jul 24, 2012 at 10:14:09AM +0200, Andre Przywara wrote:
> Actually these "strange failures" would be a bug then. If CPUID is
> not there, the feature is not there. Full stop.
That's full of b*llshit and you know it. The feature is not there
*because* some luser has disabled it with a comma
On 07/24/2012 12:14 PM, Andre Przywara wrote:
On 07/24/2012 09:06 AM, Vladimir Davydov wrote:
On 07/21/2012 02:37 PM, Borislav Petkov wrote:
(+ Andre who's been doing some cross vendor stuff)
On Fri, Jul 20, 2012 at 08:37:33PM +0400, Vladimir Davydov wrote:
If 'clearcpuid=N' is specified in b
On 07/24/2012 09:06 AM, Vladimir Davydov wrote:
On 07/21/2012 02:37 PM, Borislav Petkov wrote:
(+ Andre who's been doing some cross vendor stuff)
On Fri, Jul 20, 2012 at 08:37:33PM +0400, Vladimir Davydov wrote:
If 'clearcpuid=N' is specified in boot options, CPU feature #N won't be
reported i
On Tue, Jul 24, 2012 at 11:06:08AM +0400, Vladimir Davydov wrote:
> If msr-tools are used for cpuid masking, we will either get
> inconsistency between /proc/cpuinfo:flags and the output of the cpuid
> instruction or have to "synchronize" the clearcpuid boot option and
> the userspace app using msr
On 07/21/2012 02:37 PM, Borislav Petkov wrote:
(+ Andre who's been doing some cross vendor stuff)
On Fri, Jul 20, 2012 at 08:37:33PM +0400, Vladimir Davydov wrote:
If 'clearcpuid=N' is specified in boot options, CPU feature #N won't be
reported in /proc/cpuinfo and used by the kernel. However,
(+ Andre who's been doing some cross vendor stuff)
On Fri, Jul 20, 2012 at 08:37:33PM +0400, Vladimir Davydov wrote:
> If 'clearcpuid=N' is specified in boot options, CPU feature #N won't be
> reported in /proc/cpuinfo and used by the kernel. However, if a
> userpsace process checks CPU features d
On Jul 21, 2012, at 12:19 AM, H. Peter Anvin wrote:
> On 07/20/2012 11:21 AM, Vladimir Davydov wrote:
>>>
>>> I am a bit concerned about this patch:
>>>
>>> 1. it silently changes existing behavior.
>>
>> Yes, but who needs the current implementation of 'clearcpuid' which,
>> in fact, just hide
On 07/20/2012 11:21 AM, Vladimir Davydov wrote:
I am a bit concerned about this patch:
1. it silently changes existing behavior.
Yes, but who needs the current implementation of 'clearcpuid' which,
in fact, just hides flags in /proc/cpuinfo while userspace apps will
see and consequently use a
On Jul 20, 2012, at 9:20 PM, H. Peter Anvin wrote:
> On 07/20/2012 09:37 AM, Vladimir Davydov wrote:
>> If 'clearcpuid=N' is specified in boot options, CPU feature #N won't be
>> reported in /proc/cpuinfo and used by the kernel. However, if a
>> userpsace process checks CPU features directly using
On 07/20/2012 09:37 AM, Vladimir Davydov wrote:
> If 'clearcpuid=N' is specified in boot options, CPU feature #N won't be
> reported in /proc/cpuinfo and used by the kernel. However, if a
> userpsace process checks CPU features directly using the cpuid
> instruction, it will be reported about all f
On 07/20/2012 10:10 AM, Andi Kleen wrote:
>
> And please use rdmsrl(), rdmsr() is so 90ies
>
rdmsr()/wrmsr() make more sense in cases like this where the upper and
lower halves of the MSR actually contain separate data.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe
> + unsigned int *msr_ext_cpuid_mask)
> +{
> + unsigned int msr, msr_ext;
> +
> + msr = msr_ext = 0;
> +
> + switch (c->x86_model) {
You have to check the family too.
> +
> + return msr;
> +}
> +
> +static void __cpuinit intel_mask_cpu_caps(stru
If 'clearcpuid=N' is specified in boot options, CPU feature #N won't be
reported in /proc/cpuinfo and used by the kernel. However, if a
userpsace process checks CPU features directly using the cpuid
instruction, it will be reported about all features supported by the CPU
irrespective of what featur
34 matches
Mail list logo
