It already had limited usability before. With stack direct access optimization the callback won't be called for stack accesses as well.
See note by Brian Slechta:
=== Cut Hete ===
While using Bochs as a reference model for simulations, the simulator needs
information about what loads/stores are taking place with each instruction.
Presumably, that is what the BX_INSTR_MEM_DATA() instrumentation macros
cover (which is the place where our simulator hooks up).
The RETnear_xxx() functions call access_linear() directly, rather than call
read_virtual_xxx() functions. This is a problem for code making use of the
BX_INSTR_MEM_DATA() hook because it does not get called for these
instructions. Should this be changed along with some other instructions
that exhibit this?
=== Cut Hete ===
For Bryan's usage bx_instr_lin_access and bx_instr_phy_read/bx_instr_phy_write callbacks should be used.
but in case you want a few %% of extra emulation performance - it is still possible to disable it with configure option.
most guests I saw do not use it !
for CPU emulation performance reasons, the alignment check compilation
still can be enabled using configure option --enable-alignment-check.
There is no software in the world which enable #AC exception checking, this
x86 feature is completely legacy but its emulation support costs up to 3-5%
emulation speed.
The checking for #AC exception enable still will be done, if
CPL == 3, EFLAGS.AC = 1 and CR0.AM = 1
but the alignment check is not compiled in, the Bochs will PANIC with corresponding message.
You can press 'always continue' and ignore the PANIC, the simulation will continue as if alignment checking is not enabled.
XOP: few instructions are still missing, coming soon
BX_PANIC(("VPERMILPS_VpsHpsWpsVIbR: not implemented yet"));
BX_PANIC(("VPERMILPD_VpdHpdWpdVIbR: not implemented yet"));
BX_PANIC(("VPMADCSSWD_VdqHdqWdqVIbR: not implemented yet"));
BX_PANIC(("VPMADCSWD_VdqHdqWdqVIbR: not implemented yet"));
BX_PANIC(("VFRCZPS_VpsWpsR: not implemented yet"));
BX_PANIC(("VFRCZPD_VpdWpdR: not implemented yet"));
BX_PANIC(("VFRCZSS_VssWssR: not implemented yet"));
BX_PANIC(("VFRCZSD_VsdWsdR: not implemented yet"));
So now the same single option will choose not only the CPUID flags but also VMX capabilities matching real HW machine.
Removed cpuid of core2_extreme_x9770 from the cpudb. I don't remember its VMX capabilities anyway.
There is another Penryn model in the cpudb - core2_penryn_t9600.
It was a real challenge to summarize all the highlights we have done in past half a year.
Hopefully it looks good and I didn't miss anything important.
32-bit CPU using Bochs binary compiled with x86-64 support.
The commit also fixes some init.cc issues with initialization of SYSCALL/SYSRET MSR in AMD hosts and also includes code reorg.
SMP emulation. New implementation uses dynamic CPU quantum value and takes
full advantage of the trace cache. Each emulated processor will execute
the whole trace before switching to the next processor.
* It is also safe to use large (up to 16 instructions) quantum values for
the SMP emulation now and improve performance even further.
The same merge also completely fixes SF bug :
[3312237] stepN command might be not working properly
Handlers chaining speedups are also supported with SMP emulation now.
