lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 17 Feb 2017 15:19:04 +0100
From:   Juergen Gross <jgross@...e.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
        x86@...nel.org
Cc:     hpa@...or.com, tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH 2/2] x86/xen: use capabilities instead of fake cpuid
 values

On 17/02/17 15:05, Boris Ostrovsky wrote:
> 
> 
> On 02/17/2017 02:36 AM, Juergen Gross wrote:
>> When running as pv domain xen_cpuid() is being used instead of
>> native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
>> as not being present by special casing the related cpuid leaf.
>>
>> Instead of delivering fake cpuid values clear the cpu capability bit
>> for aperf/mperf instead.
>>
>> Signed-off-by: Juergen Gross <jgross@...e.com>
>> ---
>>  arch/x86/xen/enlighten.c | 11 +++--------
>>  1 file changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 83399ce..0eebb75 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -301,9 +301,6 @@ xen_running_on_version_or_later(unsigned int
>> major, unsigned int minor)
>>      return false;
>>  }
>>
>> -#define CPUID_THERM_POWER_LEAF 6
>> -#define APERFMPERF_PRESENT 0
>> -
>>  static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
>>  static __read_mostly unsigned int cpuid_leaf1_ecx_mask = ~0;
>>
>> @@ -337,11 +334,6 @@ static void xen_cpuid(unsigned int *ax, unsigned
>> int *bx,
>>          *dx = cpuid_leaf5_edx_val;
>>          return;
>>
>> -    case CPUID_THERM_POWER_LEAF:
>> -        /* Disabling APERFMPERF for kernel usage */
>> -        maskecx = ~(1 << APERFMPERF_PRESENT);
>> -        break;
>> -
> 
> 
> But now APERF/MPERF will be reported as supported by CPUID, won't it?

Yes. But this shouldn't be a problem as the kernel is always testing
X86_FEATURE_APERFMPERF for testing the support.

>>      case 0xb:
>>          /* Suppress extended topology stuff */
>>          maskebx = 0;
>> @@ -462,6 +454,9 @@ static void __init xen_init_cpuid_mask(void)
>>      if (xen_check_mwait())
>>          cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
>>
>> +    /* Disable APERFMPERF feature. */
>> +    setup_clear_cpu_cap(X86_FEATURE_APERFMPERF);
>> +
>>      /* Disable DCA feature. */
>>      setup_clear_cpu_cap(X86_FEATURE_DCA);
> 
> 
> I think both of those can go to xen_set_cpu_features().

Okay. I'll move them.

I think we can convert some of the remaining cpuid bit modifications to
cpu capabilities as well.


Juergen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ