OSDev.org

Bochs 2.5.1 patch release was issued on January 6th 2012.

Changes in 2.5.1 :

- CPU / CPUDB
! Added Athlon64 (Venice) configuration to the CPUDB
- BMI: fixed EFLAGS after BMI instructions
- MSR: access to AMD extended MSR space was impossible due to a bug in RDMSR/WRMSR
- VMX: fixed VMFUNC instruction behavior to align with Intel SDM revision 041
- VMX: fixed Bochs PANIC when doing I/O access crossing VMX I/O permission bitmaps
- VMX: fixed VirtualBox VMX guest Guru Meditation - FS.BASE got corrupted after
saving/restoring unusable FS selector
- VMX: fixed VirtualBox failures with VMX+EPT enabled
- Better report of supported CPUID features when not using pre-defined CPUID profile

- Debugger / Instrumentation
- fixed typo - closing SF bug [3461405] step all command fails in SMP mode
- instrumentation: added special indication for indirect call/jump

- Configure and compile
- fixed compilation err in instrumentation call (tasking.cc)
- fixed compilation err with x86 hw breakpoint enabled and CPU_LEVEL < 6
- fixed compilation issue under win32 --with-nogui
- added missing dependencies for cdrom_osx.o
- removed very old deprecated configure options from configure script

- I/O Devices
- fixed possible failures of PCI DMA transfers
- VVFAT: several fixes in the optional write support (passes test with XP)
- USB UHCI: some fixes to make it work in XP guest
- removed devices 'acpi', 'ioapic' and 'pci_ide' from optional plugin control
to avoid trouble

- Config interface / GUI and display libraries
- added VMX .bochsrc option to control VMX support on runtime
- fix for x86-64 .bochsrc option parsing (patch from @SF)
- fix for @SF bug: Crash on WIN2K - ID: 3454214
- added 'nokeyrepeat' option for the SDL and win32 gui

Stanislav

Nice, great work!

I just updated to the newest SVN version and started my build script. Everything works fine, except when I configure with both --enable-x86-64 and --enable-smp enabled. For example, one of the builds I have in my script is:
I get this error:

Thanks, fixed.

Stanislav

Compiling works like a charm now

One more thing: Have there been any changes to the "port e9 hack" for debugging output? I used to print some debug output to port e9 (and enabled it in my bochsrc file with "port_e9_hack: enabled=1") and it used to work fine, but with the new version I don't get any output.

XenOS wrote: One more thing: Have there been any changes to the "port e9 hack" for debugging output? I used to print some debug output to port e9 (and enabled it in my bochsrc file with "port_e9_hack: enabled=1") and it used to work fine, but with the new version I don't get any output.

I guess it might be realted to Volker's recent changes in plugins architecture. The port_e9_hack stuff printed from 'unmapped' device which is, I think, not necessary enabled by default now. To be in safe side I would add in .bochsrc:

plugin_ctrl: unmapped=1

Let me know if it is the case.
Anyway, it is probably good idea to write about it in Bochs-Developers mailing to drive Volker's attention. It could be good idea to get some explanation from first hands why things done this way and not another.

Stanislav

P.S. BTW, for SMP configuration you could try to use large 'quantum' values in .bochsrc CPU option to get SMP emulation faster. The default value is 5, setting quantum to 15 could improve emulation speed by 20-50%.

stlw wrote:plugin_ctrl: unmapped=1

Let me know if it is the case.

Thanks, that did the trick.

P.S. BTW, for SMP configuration you could try to use large 'quantum' values in .bochsrc CPU option to get SMP emulation faster. The default value is 5, setting quantum to 15 could improve emulation speed by 20-50%.

Indeed, there is a serious speedup, although it currently doesn't matter so much since my kernel doesn't have any real work to be done yet But I have some L4 kernel with a few benchmark tools and I'll figure out how they are affected by the quantum setting.

I just tested the L4 benchmarks with 4 CPUs and it turned out that all of them are IPC benchmarks... These are actually much faster if the quantum setting is decreased, which is of course no surprise. However, loading the kernel is much faster if the quantum setting is increased. With 16 CPUs, the effect is even larger.