linux-kernel - Re: [PATCH 2/2] x86/xen: use capabilities instead of fake cpuid values

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a4a8d0e9-8987-172d-2aec-2a1c1c07065e@oracle.com>
Date:   Fri, 17 Feb 2017 09:30:57 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Juergen Gross <jgross@...e.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 02/17/2017 09:19 AM, Juergen Gross wrote:
> 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.


But X86_FEATURE_APERFMPERF cap is set based on CPUID query.

-boris

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