I am trying to test the VM-Exit from NMI exiting.
the NMI exiting bit is 1 in VM-EXECUTION-control of VMCS.
In guest VM, i used 'int $2' to trigger a NMI, the guest NMI handler is called, but i did NOT get the VM-exit from this NMI.
so, is there anything i missed, or 'int $2' in guest VM could NOT trigger the NMI exiting? if so, what type of NMI can trigger NMI-Exiting?
Thanks,
Are AVX instructions available to an enclave?
If so, would SGX protect the entire data path of the SIMD workload?
Thanks!
more information about madvise and compare please . I have i5-3210M 2,5 GHz and 2x E5- 2609 2,4 Ghz can i use this function on this processors ? .
I need datas for i5-3210 M 2,5 GHz and 2xE 2609 2,4 GHz :
1.arithmetical and logical operations speed
2. Normal range in computational time
3. Execution precision of arithmetical operations on real numbers
4. Capacity and structure of cache .
Assuming an instruction accesses memory and stores a register's content into it, on x86_64 architecture. For Example,
bndcl rax, [rip + offset1] mov rax, [rip + offset1]
My question is, if the segmentation is enabled, and the access to same memory address was done with segment register, will it incur more overhead(latency or throughput)?For Example,
bndcl rax, gs:[rip + offset2] mov rax, gs:[rip + offset2]
It is Not possible to run latest versions of SDE, for example 7.49.0, on 32-bit Windows platforms
what does L1 ( instruction , data ) , L2 , L3 mean ?
Hi,
I have troubles with running Intel SDE for AVX-512 emulation. I've downloaded last version (sde-external-7.49.0-2016-07-07-lin) and run on Debian kernel version 4.9.0-1 x86-64. I do not use SELinux and already disabled
/proc/sys/kernel/yama/ptrace_scope
But execution gives me this error:
$ ./sde64 -skx -- binaryfile SDE ERROR: Cannot execute XGETBV with ECX != 0. at (no-file):65 Function (no-func)
Any ideas what went wrong?
Thanks
Do E-class CPUs down clock when AVX in the execution stack? if it does Why?
How can i adressed to cache memory from assembler level ?
Hi, I'm working with some on demand, latency sensitive computations which parallel well and typically take 10-30ms to complete. VTune indicates their AVX implementation is generally higher latency than SSE because SpeedStep is less aggressive in boosting core frequencies from idle with AVX. The additional width of AVX does offer a lower millisecond * GHz product than SSE. But not by so much as to be unambiguously lower power when one considers the core voltage increase applied for AVX. It's therefore unclear if it's worth dispatching to the AVX implementation on processors where AVX is available.
What's the best software method to track core voltages and such while the tasks are running? I'm not seeing VTune 2017 Update 2 includes power in its platform information and searches in this direction lead into a maze of obsolete and contradictory information. From what I can tell getConsumedJoules() in OpenPCM appears to be the currently preferred approach for high such resolution timing . But, somewhat to my surprise, OpenPCM requires a somewhat involved build and installation process, doesn't release binaries, and lacks a nuget package with a .lib one can just link to. Its license does allow extracting the few bits of code I need. But this seems an unnecessarily difficult method for such a simple calculation. I'm aware of Intel Energy Profiler but it's not part of my license and, from the description, it's unclear if it supports sampling at rates above 10Hz whereas 1+kHz is desirable here.
Is there a better way? Profiling at coding time is OK but I wouldn't mind making the app smart enough to evaluate both widths and select whichever runs better.
Hi,
to be confirmed: modification on stack pointer register (RSP/ESP) will not abort HLE/RTM?!
ty,
Oliver
Hi,
Intel's documentation 'Intel 64 and IA-32 Architectues Software Developer's Manual Vol-1' mentions in section section 16.3.8.1 that a transaction will be aborted if X87 state is modified (including all X87 instructions).
But what about fldcw? The calling convention of the 'SYSV ABI for X86_64' requires to preserve/restore the X87 control word.
Does 'all X87 instructions' include fldcw?
Oliver
Under what circumstance does a logical processor abort a RTM transaction and sets abort status 'RETRY' (bit 1 in in EAX)?
I've read 'Intel 64 and IA-32 Architectures Software/Optimization Manual' but I've some questions regarding to the RTM abort status.
Under which conditions are the bits in EAX set:
Are additional conditions possible?
I assume that conditions indicated by bits 3-5 are non-transient, e.g. restarting the transaction would not help.
best regards,
Oliver
I am not sure if this is the right forum for this topic, but given that it concerns new CPUs such as Kaby Lake I decided to start it here. Feel free to move it elsewhere, but I feel it is appropriate that people dealing with latest ISA extensions know what is going on.
As you may or may not be aware, Microsoft has decided to prevent people with Kaby Lake CPU from obtaining Windows security updates if they are using Windows 7 or Windows 8.1:
"The processor is not supported together with the Windows version that you are currently using" error when you scan or download Windows updates
"Big deal" I hear you saying already "everyone should be on Windows 10 by now", but please, hold your horses and let me explain why everyone should be up in arms.
Windows 7 is in an extended support phase which means no new features, but it should still receive security updates until End Of Life just like Windows XP did. Let's say that even though it marks a disturbing change in vendor behavior this is somewhat less important and somehow expected and move on to the crux of the problem which is Windows 8.1.
Windows 8.1 is still in a mainstream support phase which ends on January 9th, 2018 and at least until then they should not only provide security updates but also feature updates. Security updates should be available until January 10th, 2023:
Windows 8.1 Pro Lifecycle
Now take a look at this screenshot and then take a look at the calendar:
That's right, someone who paid for a Windows 8.1 license is denied support almost 9 (nine!) months before mainstream support end just because they happen to have Kaby Lake CPU! Same goes for some Sky Lake systems as well which makes the whole thing look even more stupid and arbitrary.
Everyone in this forum surely understands that the message above is a pile of stinking bovine excrement and here is why:
1. Kaby Lake CPU does not have enough architectural difference compared to Sky Lake CPU to justify this artificial software block.
2. Every Sky Lake CPU has the basic set of features needed to run Windows 8.1, yet some of them are also blocked from receiving security updates.
3. Given that all Intel CPUs released after those which were lacking LAHF/SAHF instructions are 100% backward compatible there are no special tests those new security updates would need to go through to support new CPUs on old operating systems.
4. It makes sense to cut support for old hardware, not for new, 100% backward compatible, hardware.
Given Microsoft's desktop OS monopoly I expected such a dick move from them -- after all, they want everyone to upgrade to their Windows 10 spyware so in addition to those 200 USD or EUR they extort for an OS license they can also monetize our personal data.
But what I would like to understand is why is Intel allowing this? How is this in Intel's best and/or long term interest? Shouldn't all Intel's customers regardless of the CPU model enjoy the best possible security on every OS/platform which is still in mainstream support?
I think that letting OEMs and Microsoft collude and do things like this should be met with legal penalties, because this is a typical bait and switch -- i.e. "Buy Windows 8.1 and you will get 5 year support... oh sorry you have Kaby Lake CPU now? No more support for you, but if you buy this shiny new Windows 10, you will get 5 year support...".
Putting the reasons not to upgrade to Windows 10 aside for the moment, Intel should not allow Microsoft to get away with this one. Allowing this to go through is the same kind of mistake like the one where Intel allowed OEMs to decide whether hardware virtualization option was available in BIOS or not.
Why? Because the message most consumers will get out of this is that Intel latest CPU is not compatible with older software which can't be further from the truth and it will just serve to damage Intel's brand.
Somebody do something about it before it is too late.
| Attachment | Size |
|---|---|
Download unsupported-hardware.png | 81.19 KB |
On a system with at least two NUMA nodes - will an accessing cache-lines from another NUMA node (through QPI) abort a RTM/HLE transaction?
I can't find a hint in the Intel documentation.
AFAIK, TSX uses the cc-snoop protocols so I would assume that the snoop protocol messages are not passed through the QPI.
With which error is the transaction aborted? With capacity error or memory confilct ...?
best regards,
Oliver
I read Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C, and there're 2 new packets in Processor Trace. They're not supported on my cpu, i7-6700. I want to know whether they're supported on the 7th core processor？
Hi,
I have a C console programs running under Windows 10. I have compiled it with icl. I am looking into writing __asm{ code to serialize theard processing
I am aware that windows offers event API's SetEvent CreateEvent WaitForSingleObject. since I am coding in asm I am wondering if the is a int instruction number that would suspend or resume a thread, More so where code I find a complete list of int's my processor is i7-6900k
Thanks
I'm working on an open source project to implement portable versions of SIMD intrinsics. I've been using the Intel Intrinsics Guide as a reference, and it occurs to me that it's probably generated from some machine-readable data source. If I could get a hold of that I could generate skeleton functions for both implementations and tests, which would save me a *lot* of time. Does anyone know if that data is available or could be made available?
On a related note, my compliments to anyone who worked on the guide. It's a great resource, and very well done, especially compared to the ARM NEON Intrinsics Reference (and I haven't even found anything comparable for MIPS or POWER).