On 2017-03-17 16:30, Patrick Kelsey wrote:
> On Fri, Mar 17, 2017 at 1:31 PM, O. Hartmann <ohartm...@walstatt.org> wrote:
>> Am Fri, 17 Mar 2017 20:07:35 +0300
>> Slawa Olhovchenkov <s...@zxy.spb.ru> schrieb:
>>> On Fri, Mar 17, 2017 at 05:53:24PM +0100, O. Hartmann wrote:
>>>> Am Fri, 17 Mar 2017 15:04:29 +0300
>>>> Slawa Olhovchenkov <s...@zxy.spb.ru> schrieb:
>>>>> On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
>>>>>> Running recent CURRENT on a Fujitsu Celsius M740 equipted with an
>> Intel(R)
>>>>>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble.
>>>>>> FreeBSD does not report the existence or availability of AES-NI
>> feature, which
>>>>>> is supposed to be a feature of this type of CPU:
>>>>> What reassons to detect AES-NI by FreeBSD?
>>>> What do you mean? I do not understand! FreeBSD is supposed to read the
>> CPUID and
>>>> therefore the capabilities as every other OS, too. But there may some
>> circumstances
>>>> why FBSD won't. I do not know, that is the reason why I'm asking here.
>>> This sample can have disabled AES-NI by vendor, in BIOS, for example.
>>> As I show by links this is posible.
>>> CPUID in you example don't show AES-NI capabilities, for example
>>> 1650v4 w/ AES-NI
>>> CPU: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (3600.07-MHz K8-class CPU)
>>>   Origin="GenuineIntel"  Id=0x406f1  Family=0x6  Model=0x4f  Stepping=1
>>>   Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,
>>>   Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,
>>   ^^^^^^
>>>   AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>>>   AMD Features2=0x121<LAHF,ABM,Prefetch>
>>>   Structured Extended
>>> Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,
>> VID,PostIntr
>>>   TSC: P-state invariant, performance statistics
>>> In you sample: "TSCDLT,XSAVE"
>>> May be AES-NI disabled by vendor and FreeBSD correct show this. Or some
>> bug in FreeBSD,
>>> AES-NI work and other OS show AES-NI capabilities.
>>> _______________________________________________
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> freebsd.org"
>> We have some LGA1151 XEON based 19 inch rack server, also equipted with
>> Haswell
>> E3-12XX-v3 XEONs and FreeBSD, also CURRENT, does show AES-NI.
>> You're right, the vendor could have disabled AES-NI by intention - but
>> they offered this
>> box especially with AES-NI capabilities.
>> See here:
>>   http://freebsd.1045724.x6.nabble.com/r285947-broken-
>> AESNI-support-No-aesni0-on-Intel-XEON-E5-1650-v3-on-Fujitsu-Celsius-M740-
>> td6028895.html
>> I feel a bit pissed off right now due to Fujitsu, because we started
>> testing some
>> encrypting features and I'd like to use AES-NI and I run into this issue
>> again.
>> I need to know that FreeBSD is not the issue with this specific CPU type.
>> I'm still
>> frustrated by that stupid comment "UNIX is not supoorted" I got that time
>> then when I
>> reported 2015 the issue to Fujitsu.
> It's pretty straightforward to gain confidence that FreeBSD is not the
> issue here.  The 'Features2=' line is printed by printcpuinfo() in
> sys/x86/x86/identcpu.c based on the bits set in a variable called
> cpu_feature2 (the printf is currently at line 802).  The value of
> cpu_feature2 is set in identify_cpu() identcpu.c (for amd64, currently at
> line 1401) based on the result of the cpuid instruction that is executed by
> a call to do_cpuid(), which itself resides in sys/amd64/include/cpufunc.h.
> In other words, a single asm instruction is executed and the set bits from
> the result are printed.
> Based on some poking around in open source bits (tianocore, coreboot), it
> appears that AES-NI is something the BIOS can irreversibly
> disable-until-next-reset by twiddling bits in the appropriate MSR
> register.  There is no code that does this in FreeBSD on purpose, so there
> would have to be a bug introduced in -CURRENT that somehow clobbers those
> MSR bits early on - a bug that was also not merged to 11-STABLE (since
> Slawa shows AESNI enabled on the same processor under 11-STABLE).
> I will also say that I have dealt with a manufacturer of Xeon hardware in
> Europe who will not provide a stock BIOS that allows you to enable AES-NI,
> out of concerns over violating export/import rules governing encryption
> technology.  With that vendor, you have to pass an end-user verification
> and then they will make you a custom BIOS that gives you the option to
> enable AES-NI.  It took quite some time working through the outer layers of
> their support organization to even determine that this was the underlying
> (bureaucratic) issue.
> Here is another data point: 11.0-RELEASE-p1 running on E5-1650 v3 with
> AESNI recognized as enabled.  You could install that stock FreeBSD release
> and if it does not show AESNI as enabled on your system, you will clearly
> know it is not a FreeBSD problem without any question as to whether there
> is a bug in CURRENT or having to build and install the exact rev of
> 11-STABLE that Slawa is using.
> uname:
> FreeBSD ttest2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep
> 29 01:43:23 UTC 2016
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
>  amd64
> dmesg:
> CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3500.08-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306f2  Family=0x6  Model=0x3f  Stepping=2
> -Patrick
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I can also confirm it works fine on FreeBSD 11.0-RELEASE-p1 on the
E5-1650 v3, as I did all of the testing for my recent AsiaBSDCon paper
of SSH performance, on a pair of identical E5-1650 v3's in the FreeBSD
Test Cluster @ Sentex.

Allan Jude
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to