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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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 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
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
On Wed, 25 Jul 2012 14:31:30 +0400
Vladimir Davydov vdavy...@parallels.com 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
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,
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
On 07/25/2012 03:31 PM, Alan Cox wrote:
On Wed, 25 Jul 2012 14:31:30 +0400
Vladimir Davydovvdavy...@parallels.com 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?
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
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
With the necessary infrastructure, yes. Trap and emulate is montrivial work.
Vladimir Davydov vdavy...@parallels.com 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
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
> 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
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
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
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
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
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
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
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,
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,
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
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
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
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 command
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
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 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
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
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
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
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 low-level
(+ 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
(+ 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
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
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
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
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
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
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
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
+ 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(struct
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
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
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 the
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
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 hides flags in
68 matches
Mail list logo
