4.3 配置文件 bochsrc

官网参考地址

Bochs利用一个叫做bochsrc的配置文件来说明磁盘镜像的存放位置，Bochs模拟层应该怎样工作等。当你第一次启动Bochs，它按照5.2章节中的顺序查找它的配置文件，并解析其中的配置。下面是配置文件中的一段配置样例：

  ata0-master: type=disk, path="30M.sample", cylinders=615, heads=6, spt=17
  boot: disk

Bochs文件配置格式非常严格，对空格数敏感，且使用小写字母。如你所见，大多数配置行会有一个关键字来说明这一行配置什么，后面跟着":"，然后是一些键值对，键值对通过","分隔。对于一些简单的配置项，通常只需要配置一个简单的值。源码和二进制发布版带有一个bochsrc样本文件，你只要复制这个样本文件然后根据需要编辑改变这些设置就可以了。

bochsrc文件的配置语法也适用于Bochs命令行参数。如果命令行参数有空格，应该用单引号括起来，比如：

  bochs 'boot:floppy' 'floppya: 1_44=a.img, status=inserted'

其他参数，参考命令行参数章节。

bochsrc文件中可以使用'$'符号加上环境变量，比如：

  floppya: 1_44="$IMAGES/bootdisk.img", status=inserted
  boot: floppy

在编译安装阶段内置了两个环境变量。
(sharedir)可以改变默认值。BXSHARE没有定义，Bochs使用默认值。
$LTDL_LIBRARY_PATH指明一组目录用于寻找Bochs插件。这些路径通过':'分割(windows上通过';')。Win32和MacOSX的默认值取决于平台相关的独特算法。在Win32上，我们通过注册表查看Bochs及相关支持文件被安装在哪里。在MacOSX上，share目录就是程序所在目录。

配置文件支持使用#include语句来引用其他配置文件。所以平台或安装默认配置可以房租一个全局配置文件(比如rom镜像的位置)中。把#include语句房租配置文件的最上面:

 #include /etc/bochsrc

对于那些位置的配置项，Bochs将他们作为设备插件处理。Bochs尝试加载这些插件，如果成功就为这一行配置调用插件中对应的解析函数。这个机制用于实现Bochs网络、声音以及USB设备。如果可选配置或者过期配置中有错误输出，Bochs就会panic报错退出，同时报出插件加载失败错误信息。在这种情况下，bochsrc文件的失败行必须review并修复。

以下段落列举了所有支持的bochsrc配置项。

4.3.1. plugin_ctrl

示例:

  plugin_ctrl: unmapped=0, e1000=1 # unload 'unmapped' and load 'e1000'

plugin_ctrl控制可选的设备插件是否可用。这些插件通过这个配置项直接加载，其中有些插件只有插件设备被加载之后才会安装一些配置。'1'表示加载这个插件，'0'表示不加载(如果之前已经加载就会卸载)。

这些插件如果可用将会默认直接加载：'biosdev', 'extfpuirq', 'gameport', 'iodebug','parallel', 'serial', 'speaker' and 'unmapped'。

这些插件也支持直接加载，但是他们通常直接通过他们的bochsrc配置项来加载：'e1000', 'es1370', 'ne2k', 'pcidev', 'pcipnic', 'sb16', 'usb_ehci', 'usb_ohci', 'usb_uhci', 'usb_xhci' and 'voodoo'。

4.3.2. config_interface

配置接口是一组菜单和对话框，通过这些菜单和对话框，你可以编辑所有设置来控制Bochs行为。根据平台不同，有3种配置接口的选择：文本模式称之为'textconfig'，还有两周图形化模式称之为'win32config' 和 'wx'。文本模式使用标准输入输出，是默认支持的，除非编译的时候指定只使用wx。win32config接口只使用于win32，并且在win32上默认使用win32config。只有Bochs在编译的时候支持wxWidgets，wx接口才可用，详见章节3.4.12.如果你不配置config_interface，Bochs会为你选择默认接口(通常是textconfig)。

注意：wxWidgets同时包括配置接口和显示库。所以如果你使用'wx'配置接口，你必须同时使用'wx'显示库，详见display_library章节

示例:

  config_interface: textconfig
  config_interface: win32config
  config_interface: wx

4.3.3. display_library

显示库用于显示Bochs的VGA屏幕。Bochs大约有10种可选的显示库从而适配不同的平台。在运行Bochs时，附带--with-*参数，display_library配置项允许你选择你想要的显示库。如果不配置display_library，Bochs会选择一个默认库。

注意：wxWidgets同时包括配置接口和显示库。所以如果你使用'wx'显示库，你必须同时使用'wx'配置接口，详见config_interface章节

示例:

  display_library: x
  display_library: sdl

有些显示库现在支持单独配置项，从而控制他们的行为。这些配置项配置项是多个显示库共同支持的：

  "gui_debug"   - use GTK debugger gui (sdl, x) / Win32 debugger gui (sdl, sdl2, win32)
  "hideIPS"     - disable IPS output in status bar (rfb, sdl, sdl2, vncsrv, win32, wx, x)
  "nokeyrepeat" - turn off host keyboard repeat (sdl, sdl2, win32, x)
  "timeout"     - time (in seconds) to wait for client (rfb, vncsrv)

下面是现在支持的其他配置项示例

  display_library: sdl, options="fullscreen"  # startup in fullscreen mode
  display_library: sdl2, options="fullscreen"  # startup in fullscreen mode

• 表 4-2 display_library 值

4.3.4. cpu

示例：

  cpu: count=2, ips=10000000

这个配置定义了Bochs内部的CPU参数：

• model
  根据所有支持的配置项预先定义好配置列表，从中选择CPU配置来模拟。当这个配置项配置且值不是'bx_generic',CPUID配置项将不再生效。详见5.4章节

• count
  当Bochs编译时是SMP模拟器时，这个配置项 设置处理器数量:每个处理器的核心数:每个核心的线程数。Bochs现在可以支持14线程(legacy APIC)或者254线程(xAPIC及更高版本中断控制器)同时运行。如果Bochs在编译阶段没有支持SMP，那么这个配置项不接受除了1之外的值。更多SMP相关信息参考8.9章节

• quantum
  这个配置项设置在将控制权返回给另一个cpu之前，处理器允许执行的最大指令数。这个配置的生效需要在Bochs编译时支持SMP。

• reset_on_triple_fault
  这个配置项设置重置CPU的时机是在发生triple错误时，而不是PANIC。注意：如果你在发生triple错误之后仍试图继续，Bochs的模拟行为是完全虚假的。

• cpuid_limit_winnt
  这个配置项决定是否将最大CPUID功能限制为2。在安装和启动WinNT时，需要设置这个配置。

• mwait_is_nop
  当这个配置项被启用，MWAIT指令将不会设置CPU进入睡眠状态。这个配置的生效需要在Bochs编译时加上--enable-monitor-mwait编译选项。

• msrs
  这个配置项定义用户CPU msr 寄存器规范的路径。参考mers.def示例。

• ignore_bad_msrs
  忽略Bochs不识别的MSR参考文献；打印一个告警信息而不是产生一个常规保护异常(#GP)。这个配置项默认被启用，但是如果msrs配置项优先级更高。

• ips
  每秒模拟的指令数。这是Bochs在你的机器上能够运行的IPS数值。你可以加上--enable-show-ips编译选项重新编译Bochs，这样就可以查看你的工作站的算力了。实测的IPS值会被记录在你的日志文件或者状态栏里(如果GUI支持的话)。
  在Bochs模拟器中IPS用于校准很多时间依赖性事件。比如，改变IPS将会影响VGA更新频率、按键开始自动重复的间隔时间、以及BogoMips和其他基准的测量。下面的表格列出了不同机器的一些典型IPS设置。

表 4-3. IPS 设置示例

4.3.5. cpuid

示例:

  cpuid: level=6, mmx=1, sep=1, sse=sse4_2, apic=xapic, aes=1, movbe=1, xsave=1

这个配置项定义Bochs模拟的CPU支持的特性和功能。这些设置只有在CPU型号(参考4.3.4)设置为默认值bx_generic时才是合法可配置的。

• level
  这个配置项设置模拟CPUID指令返回的CPU级别信息。默认值取决于编译选项--enable-cpu-level。当前支持的值是5(对Pentium和相近的处理器生效)6(对P6以及更新的处理器生效)。

• family
  这个配置项设置模拟CPUID指令返回的family信息。默认的family值由编译选项--enable-cpu-level确定。

• model
  这个配置项设置CPUID指令返回的model信息。默认的model值是3。

• stepping
  这个配置项设置CPUID指令返回的 信息。默认的stepping值是3。

• vendor_string
  这个配置项设置CPUID指令返回的vendor信息。这个值应该是一个12字符的ASCII字符串。

• brand_string
  这个配置项设置CPUID指令返回的brand信息。这个值应该是一个最长48字符的ASCII字符串。

• mmx
  选择支持MMX指令集。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 5。

• apic
  这个配置项设置APIC(高级可编程中断控制器)。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 5。

• sep
  选择支持SYSENTER/SYSEXIT指令。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• simd
  选择支持SIMD指令。NONE/SSE/SSE2/SSE3/SSSE3/SSE4_1/SSE4_2/AVX/AVX2/AVX512中任意指令都可以选择支持。这个配置是生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。其中选择支持AVX的话需要Bochs编译时指定编译选项--enable-avx。

• sse4a
  选择支持AMD SSE4A指令集。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• misaligned_sse
  选择支持AMD未校准SSE模式。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• aes
  选择支持AES指令集。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• sha
  选择支持SHA指令集。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• ovbe
  选择支持MOVBE Intel(R) Atom指令。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• adx
  选择支持ADCX/ADOX指令。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• xsave
  选择支持XSAVE拓展。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• xsaveopt
  选择支持XSAVEOPT指令。这个配置生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• avx_f16c
  选择支持AVX float16转换指令。这个配置生效需要在Bochs编译时指定编译选项--enable-avx。

• avx_fma
  选择支持AVX FMA(积和熔加运算，处理浮点数时只有一次的数值修约)。这个配置生效需要在Bochs编译时指定编译选项--enable-avx。

• bmi
  选择支持 BMI1/BMI2 指令。这个配置生效需要在Bochs编译时指定编译选项--enable-avx。

• fma4
  选择支持AMD四操作数FMA指令(积和熔加运算，处理浮点数时只有一次的数值修约)。这个配置生效需要在Bochs编译时指定编译选项--enable-avx。

• xop
  选择支持 AMD XOP 指令。这个配置生效需要在Bochs编译时指定编译选项--enable-avx。

• tbm
  选择支持AMD TBM指令。这个配置生效需要在Bochs编译时指定编译选项--enable-avx。

• x86_64
  配置支持long mode(长模式)。这个这个配置的生效需要在Bochs编译是指定支持x86-64。

• 1g_pages
  配置在long mode(长模式)下支持1G内存页。这个这个配置的生效需要在Bochs编译是指定支持x86-64。

• pcid
  配置在long mode(长模式)下支持启用进程上下文标识符（PCID）。这个这个配置的生效需要在Bochs编译是指定支持x86-64。

• smep
  配置支持SMAP(监督模式执行保护)。这个配置的生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• smap
  配置支持SMAP(监督模式访问保护)。这个配置的生效需要在Bochs编译时指定编译选项BX_CPU_LEVEL >= 6。

• mwait
  选择支持MONITOR/MWAIT指令。这个配置的生效需要在Bochs编译时加上--enable-monitor-mwait编译选项。

• vmx
  选择支持VMX扩展模拟。这个配置的生效需要在Bochs编译时加上--enable-vmx编译选项。

• svm
  选择支持AMD安全虚拟机扩展模拟。这个配置的生效需要在Bochs编译时加上--enable-svm编译选项。

4.3.6. memory

示例:

  memory: guest=512, host=256

这个配置项设置Bochs需要模拟的物理内存。

• guest
  设置套模拟的客户机物理内存。默认值是32MB，这个值的最大值只受限于物理地址空间的上限。

• host
  设置你希望分配给客户机用来模拟RAM的宿主机内存。实际分配的内存可能小于你在客户机中想要模拟的内存。这会欺骗客户机去查看没有可用内存。当客户机系统检测到新的内存块，将会动态的从内存池中分走。当客户机耗尽分配的物理内存并想申请更多时，会发出警告。

注意: 由于宿主机操作系统限制，Bochs在32位操作系统上不能分配超过1024MB的内存。为了克服这个问题请在构建Bochs时带上--enable-large-ramfile编译选项。

4.3.7. megs

示例:

  megs: 32
  megs: 128

这个配置项将'guest'和'host'内存设置为同一个值。除此(宿主机和客户机内存相同)之外的其他所有情景，请使用memory配置项代替。

4.3.8. romimage

示例:

  romimage: file=bios/BIOS-bochs-latest, options=fastboot
  romimage: file=$BXSHARE/BIOS-bochs-legacy
  romimage: file=mybios.bin, address=0xfff80000

ROM BIOS控制PC第一次开机时的行为。一般来讲，你可以在源代码或者二进制发布版本的Bochs中使用一个预先编译号的BIOS。默认的ROM BIOS一般从地址 0xfffe0000 开始加载，并且是严格的128KB大小。你可以通过环境变量$BXSHARE去指定BIOS的位置。现在支持在内存顶部使用外部大BIOS映像（高达512k），但我们仍然建议使用随Bochs分发的BIOS。 起始地址是可选的，因为可以通过镜像大小计算出来。Bochs BIOS现在只支持通过"fastboot"选项去跳过启动菜单。

4.3.9. vgaromimage

示例:

  vgaromimage: file=bios/VGABIOS-elpin-2.40
  vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest
  vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest-cirrus

这个配置项设置Bochs加载VGA ROM BIOS(从 0xC0000)。
Bochs的源码和二进制版本中已经提供了来自 Elpin Systems 公司的VGA BIOS 以及一个 LGPL协议的VGA BIOS。

注意：确认VGA配置以决定使用哪一个VGA BIOS。

4.3.10. optromimage1, optromimage2, optromimage3 or optromimage4

示例:

   optromimage1: file=optionalrom.bin, address=0xd0000

这个配置项设置最多让Bochs可以支持4个可选的ROM镜像。
确保使用一个只读区域，通常地址范围在C800和EFFF之间。这些可选的ROM镜像不应该重写rombios(地址F0000-FFFFF)和videobios(地址C0000-C7FFF)中的内容。
如果这些ROM镜像包含了正确的签名(0x55AA)，将会被BIOS初始化。
它还可以方便地在模拟器中上传任意代码/数据，这些代码/数据可以由引导加载程序检索。

4.3.11. vga

示例:

  vga: extension=cirrus, update_freq=10, realtime=1
  vga: extension=vbe

这个配置项定义VGA显示相关的配置参数。

• extension
  'extension'选项用来指定VGA显示插件。如果配置值为'none'则可以使用标准的没有扩展的VGA。其他支持的配置值分别是：'vbe'，表示使用Bochs VBE(需要使用VGABIOS-lgpl-latest作为VGA BIOS，参考vgaromimage配置项)；'cirrus'，表示支持Cirrus SVGA((需要使用VGABIOS-lgpl-latest作为VGA BIOS)；'voodoo'，表示支持Voodoo Graphics(需要使用其他VGA BIOS，参考章节8.21)。

• update_freq
  VGA更新频率指定了每秒显示更新的次数。这个参数可以在运行时修改，默认值是5。

• realtime
  'realtime'配置项指定VGA更新定时器的操作模式。如果设置为1，VGA定时器将实时更新，否则将基于IPS设置进行更新。如果宿主机很慢(ips，和更新频率较低)并且客户机使用适当的使用HLT，将这个值设置成0，同时"clock: sync=none"可以在客户机其他空闲情况下提高客户机图形界面的响应。默认值是1。

4.3.12. voodoo

示例:

  voodoo: enabled=1, model=voodoo1

这个配置项定义Voodoo图形模拟(实验性的)。当前支持的模式分别是'voodoo1', 'voodoo2', 'banshee' 和 'voodoo3'。Voodoo2支持还不完全，但是大部分功能可用了。Banshee 和Voodoo3还在构件中，但是基础功能可用。2D/3D卡需要额外的VGA BIOS支持，且vga extension(4.3.11)需要设置为'voodoo'。如果选择实验i440BXPCI芯片，他们可以被集成到AGP中(5号插口)。所有模式的GUI屏幕更新时长都受'vga'配置项相关参数控制。详情参考8.21章节。

4.3.13. keyboard

示例:

  keyboard: type=mf, serial_delay=200, paste_delay=100000
  keyboard: keymap=gui/keymaps/x11-pc-de.map
  keyboard: user_shortcut=ctrl-alt-del

这个配置项定义键盘模拟相关的参数。

• type
  配置对键盘控制器使用"identify keybord"命令的返回值。可选的值只有"xt", "at" 或者 "mf"。默认是"mf"，这个配置对几乎所有人都够用了。一个已知的例外是法语版的macs，需要配置成类"at"键盘。

• serial_delay
  串行方式从键盘输入一个字符到键盘控制器的延迟时间，以毫秒为单位。

• paste_delay
  粘贴字符到键盘控制器的延迟时间，以毫秒为单位。这个延迟为客户机操作系统预留时间去处理字符流。
  Approximate time in microseconds between attempts to paste characters to the keyboard controller. This leaves time for the guest os to deal with the flow of characters. The ideal setting depends on how your operating system processes characters. The default of 100000 usec (.1 seconds) was chosen because it works consistently in Windows.

If your OS is losing characters during a paste, increase the paste delay until it stops losing characters.

• keymap

This enables a remap of a physical localized keyboard to a virtualized us keyboard, as the PC architecture expects.

Keyboard mapping is available for the display libraries x, sdl (Linux port) and wx (GTK port). For SDL you have to use keymaps designed for SDL, the wxWidgets GUI uses the keymaps for X11.

• user_shortcut

This defines the keyboard shortcut to be sent when you press the "user" button in the headerbar. The shortcut string is a combination of maximum 3 key names (listed below) separated with a '-' character.

Valid key names:

"alt", "bksl", "bksp", "ctrl", "del", "down", "end", "enter", "esc", "f1", ... "f12", "home", "ins", "left", "menu", "minus", "pgdwn", "pgup", "plus", "power", "print", "right", "scrlck", "shift", "space", "tab", "up" and "win".

4.3.14. mouse

示例:

  mouse: enabled=1
  mouse: type=imps2, enabled=1
  mouse: type=serial, enabled=1
  mouse: enabled=0, toggle=ctrl+f10

This defines parameters for the emulated mouse type, the initial status of the mouse capture and the runtime method to toggle it.

• type

With the mouse type option you can select the type of mouse to emulate. The default value is 'ps2'. The other choices are 'imps2' (wheel mouse on PS/2), 'serial', 'serial_wheel', 'serial_msys' (one com port requires setting 'mode=mouse', see com option) 'inport' and 'bus' (if present). To connect a mouse to a USB port, see the usb_uhci, 'usb_ohci', 'usb_ehci' or 'usb_xhci' options (requires PCI and USB support).

• enabled

The Bochs gui creates mouse "events" unless the 'enabled' option is set to 0. The hardware emulation itself is not disabled by this. Unless you have a particular reason for enabling the mouse by default, it is recommended that you leave it off. You can also toggle the mouse usage at runtime (see headerbar and the 'toggle' option below).

• toggle

The default method to toggle the mouse capture at runtime is to press the CTRL key and the middle mouse button ('ctrl+mbutton'). This option allows to change the method to 'ctrl+f10' (like DOSBox) or 'ctrl+alt' (like QEMU) or 'f12'.

4.3.15. pci

Examples:

pci: enabled=1, chipset=i440fx # default if compiled with PCI support
pci: enabled=1, chipset=i440fx, slot1=pcivga, slot2=ne2k
pci: enabled=1, chipset=i440bx, slot5=voodoo, slot1=e1000

This option controls the presence of a PCI chipset in Bochs. Currently it supports the i430FX, i440FX and i440BX chipsets. You can also specify the devices connected to PCI slots. Up to 5 slots are available. For these combined PCI/ISA devices assigning to slot is mandatory if you want to emulate the PCI model: cirrus, ne2k and pcivga. These PCI-only devices are also supported, but they are auto-assigned if you don't use the slot configuration: e1000, es1370, pcidev, pcipnic, usb_ehci, usb_ohci, usb_xhci and voodoo. In case of the i440BX chipset, slot #5 is the AGP slot. Currently only the 'voodoo' device can be assigned to AGP.

4.3.16. clock

This defines the parameters of the clock inside Bochs:

• sync

This defines the method how to synchronize the Bochs internal time with realtime. With the value 'none' the Bochs time relies on the IPS value and no host time synchronization is used. The 'slowdown' method sacrifices performance to preserve reproducibility while allowing host time correlation. The 'realtime' method sacrifices reproducibility to preserve performance and host-time correlation. It is possible to enable both synchronization methods.

• rtc_sync

If this option is enabled together with the realtime synchronization, the RTC runs at realtime speed. This feature is disabled by default.

• time0

Specifies the start (boot) time of the virtual machine. Use a time value as returned by the time(2) system call or a string as returned by the ctime(3) system call. If no time0 value is set or if time0 equal to 1 (special case) or if time0 equal 'local', the simulation will be started at the current local host time. If time0 equal to 2 (special case) or if time0 equal 'utc', the simulation will be started at the current utc time.

• Syntax:
  clock: sync=[none|slowdown|realtime|both], time0=[timeValue|local|utc]

Examples:
clock: sync=none, time0=local # Now (localtime)
clock: sync=slowdown, time0=315529200 # Tue Jan 1 00:00:00 1980
clock: sync=none, time0="Mon Jan 1 00:00:00 1990" # 631148400
clock: sync=realtime, time0=938581955 # Wed Sep 29 07:12:35 1999
clock: sync=realtime, time0="Sat Jan 1 00:00:00 2000" # 946681200
clock: sync=none, time0=1 # Now (localtime)
clock: sync=none, time0=utc # Now (utc/gmt)

Default value are sync=none, rtc_sync=0, time0=local

4.3.17. cmosimage

Example:

cmosimage: file=cmos.img, rtc_init=time0

This defines a binary image file with size 128 bytes that can be loaded into the CMOS RAM at startup. The rtc_init parameter controls whether initialize the RTC with values stored in the image. By default the time0 argument given to the clock option is used. With 'rtc_init=image' the image is the source for the initial time.

4.3.18. private_colormap

Example:

private_colormap: enabled=1

Requests that the GUI creates and uses its own non-shared colormap. This colormap will be used when in the Bochs window. If not enabled, a shared colormap scheme may be used. Once again, enabled=1 turns on this feature and 0 turns it off.

4.3.19. floppya/floppyb

Examples:

2.88M 3.5" media:
floppya: 2_88=a:, status=inserted
1.44M 3.5" media (write protected):
floppya: 1_44=floppya.img, status=inserted, write_protected=1
1.2M 5.25" media:
floppyb: 1_2=/dev/fd0, status=inserted
720K 3.5" media:
floppya: 720k=/usr/local/bochs/images/win95.img, status=inserted
auto-detect floppy media type:
floppya: image=floppy.img, status=inserted
use directory as VFAT media:
floppya: 1_44=vvfat:path, status=inserted
1.44M 3.5" floppy drive, no media:
floppya: type=1_44

Floppya is the first drive, and floppyb is the second drive. If you're booting from a floppy, floppya should point to a bootable disk. To read from a disk image, write the name of the image file. In many operating systems Bochs can read directly from a raw floppy drive. For raw disk access, use the device name (Unix systems) or the drive letter and a colon (Windows systems).

Following floppy media types are supported: 2_88, 1_44, 1_2, 720k, 360k, 320k, 180k, 160k, as well as "image" to let Bochs auto-detect the type of floppy media (does only work with images, not with raw floppy drives). In that case the size must match one of the supported types.

You can set the initial status of the media to ejected or inserted. Usually you will want to use inserted.

The parameter 'type' can be used to enable the floppy drive without media and status specified. Usually the drive type is set up based on the media type.

The optional parameter 'write_protected' can be used to control the media write protect switch. By default it is turned off.

4.3.20. ata0, ata1, ata2, ata3

Examples:

ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15
ata2: enabled=1, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11
ata3: enabled=1, ioaddr1=0x168, ioaddr2=0x360, irq=9

These options enables up to 4 ata channels. For each channel the two base io addresses and the irq must be specified. ata0 and ata1 are enabled by default, with the values shown above.

4.3.21. ata0-master, ata0-slave, ata1-, ata2-, ata3-*

Examples:

ata0-master: type=disk, path=10M.img, mode=flat, cylinders=306, heads=4, spt=17, translation=none
ata1-master: type=disk, path=2GB.cow, mode=vmware3, cylinders=5242, heads=16, spt=50, translation=echs
ata1-slave: type=disk, path=3GB.img, mode=sparse, cylinders=6541, heads=16, spt=63, translation=auto
ata2-master: type=disk, path=7GB.img, mode=undoable, cylinders=14563, heads=16, spt=63, translation=lba
ata2-slave: type=cdrom, path=iso.sample, status=inserted

This defines the type and characteristics of all attached ata devices:

Table 4-4. ata devices configuration options
Option Comments Possible values
type type of attached device [disk | cdrom]
path path of the image
mode image type, only valid for disks [flat | concat | external | dll | sparse | vmware3 | vmware4 | undoable | growing | volatile | vpc | vbox | vvfat ]
cylinders only valid for disks
heads only valid for disks
spt only valid for disks
status only valid for cdroms [inserted | ejected]
biosdetect type of biosdetection [auto | cmos | none]
translation type of translation done by the BIOS (legacy int13), only for disks [none | lba | large | rechs | auto]
model string returned by identify device ATA command
journal optional filename of the redolog for undoable, volatile and vvfat disks

You have to tell the type of the attached device. For Bochs 2.0 or later, it can be disk or cdrom.

You have to point the "path" at a hard disk image file, cdrom iso file, or physical cdrom device. To create a hard disk image, try running bximage (see Section 8.2). It will help you choose the size and then suggest a line that works with it.

In Unix it is possible to use a raw device as a Bochs hard disk, but we don't recommend it for safety reasons. In Windows, there is no easy way.

Disk geometry autodetection works with images created by bximage if CHS is set to 0/0/0 (cylinders are calculated using heads=16 and spt=63). For other hard disk images and modes the cylinders, heads, and spt are mandatory. In all cases the disk size reported from the image must be exactly CHS*512. Flat hard disk images from other projects might store additional information at the end of the file that makes this check fail. Only in this case it is safe to select "continue" when Bochs panics.

The disk translation scheme (implemented in legacy int13 BIOS functions, and used by older operating systems like MS-DOS), can be defined as:

none : no translation, for disks up to 528MB (1032192 sectors)

large : a standard bitshift algorithm, for disks up to 4.2GB (8257536 sectors)

rechs : a revised bitshift algorithm, using a 15 heads fake physical geometry, for disks up to 7.9GB (15482880 sectors). (don't use this unless you understand what you're doing)

lba : a standard lba-assisted algorithm, for disks up to 8.4GB (16450560 sectors)

auto : autoselection of best translation scheme. (it should be changed if system does not boot)

Please see Section 8.17.2 for a discussion on translation scheme.

The mode option defines how the disk image is handled. Disks can be defined as:

flat : one file flat layout

concat : multiple files layout

external : developer's specific, through a C++ class

dll : developer's specific, through a DLL

sparse : stackable, commitable, rollbackable

vmware3 : vmware version 3 disk support

vmware4 : vmware version 4 disk support (aka VMDK)

undoable : read-only base file with commitable redolog

growing : growing file

volatile : read-only base file with volatile redolog

vpc: fixed / dynamic size VirtualPC image

vbox: fixed / dynamic size Oracle(tm) VM VirtualBox image (VDI version 1.1)

vvfat: local directory appears as VFAT disk (with volatile redolog / optional commit)

Please see Section 8.22 for a discussion on disk modes.

Default values are:

mode=flat, biosdetect=auto, translation=auto, model="Generic 1234"

The biosdetect option has currently no effect on the BIOS.

Note: Make sure the proper ata option is enabled when using a device on that ata channel.

4.3.22. boot

Examples:

boot: floppy
boot: cdrom, disk
boot: network, disk
boot: cdrom, floppy, disk

This defines the boot sequence. You can specify up to 3 boot drives, which can be 'floppy', 'disk', 'cdrom' or 'network' (boot ROM). Legacy 'a' and 'c' are also supported.

4.3.23. floppy_bootsig_check

Example:

floppy_bootsig_check: disabled=1

This disables the 0xaa55 signature check on boot floppies The check is enabled by default.

4.3.24. log

Examples:

log: bochsout.txt
log: -
log: /dev/tty (Unix only)
log: /dev/null (Unix only)
log: nul (win32 only)

Give the path of the log file you'd like Bochs debug and misc. verbiage to be to be written to. If you don't use this option or set the filename to '-' the output is written to the console. If you really don't want it, make it "/dev/null" (Unix) or "nul" (win32). :^(

4.3.25. logprefix

Examples:

logprefix: %t-%e-@%i-%d
logprefix: %i%e%d

This handles the format of the string prepended to each log line. You may use those special tokens :

%t : 11 decimal digits timer tick
%i : 8 hexadecimal digits of current cpu eip (ignored in SMP configuration)
%e : 1 character event type ('i'nfo, 'd'ebug, 'p'anic, 'e'rror)
%d : 5 characters string of the device, between brackets

Default is %t%e%d

4.3.26. debug/info/error/panic

Examples:

debug: action=ignore, pci=report
info: action=report
error: action=report
panic: action=ask

During simulation, Bochs encounters certain events that the user might want to know about. These events are divided into four levels of importance: debug, info, error, and panic. Debug messages are usually only useful when writing Bochs code or when trying to locate a problem. There may be thousands of debug messages per second, so be careful before turning them on. Info messages tell about interesting events that don't happen that frequently. Bochs produces an "error" message when it finds a condition that really shouldn't happen, but doesn't endanger the simulation. An example of an error might be if the emulated software produces an illegal disk command. Panic messages mean that Bochs cannot simulate correctly and should probably shut down. A panic can be a configuration problem (like a misspelled bochsrc line) or an emulation problem (like an unsupported video mode).

The debug, info, error, and panic lines in the bochsrc control what Bochs will do when it encounters each type of event. The allowed actions are: fatal (terminate bochs), ask (ask the user what to do), warn (show dialog with message and continue), report (print information to the console or log file), or ignore (do nothing). The recommended settings are listed in the sample above.

It is also possible to specify the 'action' to do for each Bochs facility separately (e.g. crash on panics from everything except the cdrom, and only report those). See the log function module table for valid module names.

Tip: The safest action for panics is "fatal" or "ask". If you are getting lots of panics and get tired of telling it to continue each time, you can try action=report instead. If you allow Bochs to continue after a panic, don't be surprised if you get strange behavior or crashes after a panic occurs. Please report panic messages to the bochs-developers mailing list unless it is just a configuration problem like "could not find hard drive image."

4.3.27. debugger_log

Examples:

debugger_log: debugger.out
debugger_log: /dev/null (Unix only)
debugger_log: -

Give the path of the log file you'd like Bochs to log debugger output. If you really don't want it, make it '/dev/null', or '-'.

4.3.28. com[1-4]

Examples:

com1: enabled=1, mode=null
com1: enabled=1, mode=mouse
com1: enabled=1, mode=term, dev=/dev/ttyp9
com2: enabled=1, mode=file, dev=serial.out
com3: enabled=1, mode=raw, dev=com1
com3: enabled=1, mode=socket-client, dev=localhost:8888
com3: enabled=1, mode=socket-server, dev=localhost:8888
com4: enabled=1, mode=pipe-client, dev=\.\pipe\mypipe
com4: enabled=1, mode=pipe-server, dev=\.\pipe\mypipe

This defines a serial port (UART type 16550A).

When using the mode 'term', you can specify a device to use as com1. This can be a real serial line, or a pty. To use a pty (under X/Unix), create two windows (xterms, usually). One of them will run Bochs, and the other will act as com1. Find out the tty of the com1 window using the tty' command, and use that as thedev' parameter. Then do `sleep 1000000' in the com1 window to keep the shell from messing with things, and run Bochs in the other window. Serial I/O to com1 (port 0x3f8) will all go to the other window.

When using socket* and pipe* (win32 only) modes Bochs becomes either socket/named pipe client or server. In client mode it connects to an already running server (if connection fails Bochs treats com port as not connected). In server mode it opens socket/named pipe and waits until a client application connects to it before starting simulation. This mode is useful for remote debugging (e.g. with gdb's "target remote host:port" command or windbg's command line option -k com:pipe,port=\.\pipe\pipename). Socket modes use simple TCP communication, pipe modes use duplex byte mode pipes.

Other serial modes are 'null' (no input/output), 'file' (output to a file specified as the 'dev' parameter and changeable at runtime), 'raw' (use the real serial port - partly implemented on win32), 'mouse' (standard serial mouse - requires mouse option setting 'type=serial', 'type=serial_wheel' or 'type=serial_msys').

4.3.29. parport[1-2]

Examples:

parport1: enabled=1, file="parport.out"
parport2: enabled=1, file="/dev/lp0"
parport1: enabled=0

This defines a parallel (printer) port. When turned on and an output file is defined, the emulated printer port sends characters printed by the guest OS into the output file. On some platforms, a device filename can be used to send the data to the real parallel port (e.g. "/dev/lp0" on Linux, "lpt1" on win32 platforms). The output file can be changed at runtime.

4.3.30. sound

Example for one driver (uses platform-default):

sound: driver=default, waveout=/dev/dsp

Example for different drivers:

sound: waveoutdrv=sdl, waveindrv=alsa, midioutdrv=dummy

This defines the lowlevel sound driver(s) for the wave (PCM) input / output and the MIDI output feature and (if necessary) the devices to be used. It can have several of the following properties. All properties are in the format sound: property=value.

waveoutdrv: This defines the driver to be used for the waveout feature. Possible values are 'file' (all wave data sent to file), 'dummy' (no output) and the platform-dependant drivers 'alsa', 'oss', 'osx', 'sdl' and 'win'.

waveout: This defines the device to be used for wave output (if necessary) or the output file for the 'file' driver.

waveindrv: This defines the driver to be used for the wavein feature. Possible values are 'dummy' (recording silence) and platform-dependent drivers 'alsa', 'oss', 'sdl' and 'win'.

wavein: This defines the device to be used for wave input (if necessary).

midioutdrv: This defines the driver to be used for the MIDI output feature. Possible values are 'file' (all MIDI data sent to file), 'dummy' (no output) and platform-dependent drivers 'alsa', 'oss', 'osx' and 'win'.

midiout: This defines the device to be used for MIDI output (if necessary).

driver: This defines the driver to be used for all sound features with one property. Possible values are 'default' (platform default) and all other choices described above. Overriding one or more settings with the specific driver parameter is possible. 

See Section 5.6 for more information.

4.3.31. speaker

Example:

speaker: enabled=1, mode=sound

This defines the PC speaker output mode. In the 'sound' mode the beep is generated by the square wave generator which is a part of the lowlevel sound support. The 'system' mode is only available on Linux and Windows. On Linux /dev/console is used for output and on Windows the Beep() function. The 'gui' mode forwards the beep to the related gui methods (currently only used by the Carbon gui).

4.3.32. sb16

Example:

sb16: midimode=2, midifile=output.mid, wavemode=3, wavefile=output.wav
loglevel=2, log=sb16.log, dmatimer=600000

Note: The example is wrapped onto several lines for formatting reasons, but it should all be on one line in the actual bochsrc file.

This defines the Sound Blaster 16 emulation, see the developer documentation for more information. It can have several of the following properties. All properties are in the usual "property=value" format.

enabled: This optional property controls the presence of the SB16 emulation. The emulation is turned on unless this property is used and set to 0.

midimode: This parameter specifies what to do with the MIDI output.

    0 = no output
    1 = output to device specified with the sound option (system dependent)
    2 = MIDI or raw data output to file (depends on file name extension)
    3 = dual output (mode 1 and 2 at the same time)
   

midifile: This is the file where the midi output is stored (midimode 2 or 3).

wavemode: This parameter specifies what to do with the PCM output.

    0 = no output
    1 = output to device specified with the sound option (system dependent)
    2 = VOC, WAV or raw data output to file (depends on file name extension)
    3 = dual output (mode 1 and 2 at the same time)
   

wavefile: This is the file where the wave output is stored (wavemode 2 or 3).

log: The file to write the sb16 emulator messages to.

loglevel:

   0 = No log.
   1 = Resource changes, midi program and bank changes.
   2 = Severe errors.
   3 = All errors.
   4 = All errors plus all port accesses.
   5 = All errors and port accesses plus a lot of extra information.
   

It is possible to change the loglevel at runtime.

dmatimer: Microseconds per second for a DMA cycle. Make it smaller to fix non-continuous sound. 750000 is usually a good value. This needs a reasonably correct setting for the ips parameter of the cpu option. It is possible to adjust the dmatimer value at runtime. 

4.3.33. es1370

Examples:

es1370: enabled=1, wavemode=1 # use 'sound' parameters
es1370: enabled=1, wavemode=2, wavefile=output.voc # send output to file

This defines the ES1370 sound emulation (recording and playback - except DAC1+DAC2 output at the same time). The parameter 'enabled' controls the presence of the device. The wave and MIDI output can be sent to device, file or both using the parameters 'wavemode', 'wavefile', 'midimode' and 'midifile'. See the description of these parameters at the SB16 directive.

4.3.34. ne2k

The ne2k line configures an emulated NE2000-compatible Ethernet adapter, which allows the guest machine to communicate on the network. To disable the NE2000 just comment out the ne2k line.

Examples:

ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:00, ethmod=fbsd, ethdev=xl0
ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:00, ethmod=fbsd, ethdev=en0 #macosx
ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:00, ethmod=linux, ethdev=eth0
ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:01, ethmod=win32, ethdev=MYCARD
ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:01, ethmod=vde, ethdev="/tmp/vde.ctl"
ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:01, ethmod=vnet, ethdev="c:/temp"
ne2k: ioaddr=0x300, irq=9, mac=fe:fd:00:00:00:01, ethmod=tap, ethdev=tap0
ne2k: ioaddr=0x300, irq=9, mac=fe:fd:00:00:00:01, ethmod=tuntap, ethdev=/dev/net/tun0, script=./tunconfig
ne2k: mac=b0:c4:20:00:00:01, ethmod=socket, ethdev=40000 # use localhost
ne2k: mac=b0:c4:20:00:00:01, ethmod=socket, ethdev=mymachine:40000
ne2k: mac=b0:c4:20:00:00:01, ethmod=slirp, script=slirp.conf, bootrom=ne2k_pci.rom

IOADDR, IRQ: You probably won't need to change ioaddr and irq, unless there
are IRQ conflicts. These parameters are ignored if the NE2000 is assigned to
a PCI slot.

MAC: The MAC address MUST NOT match the address of any machine on the net.
Also, the first byte must be an even number (bit 0 set means a multicast
address), and you cannot use ff:ff:ff:ff:ff:ff because that's the broadcast
address. For the ethertap module, you must use fe:fd:00:00:00:01. There may
be other restrictions too. To be safe, just use the b0:c4... address.

ETHMOD: The ethmod value defines which low level OS specific module to be
used to access physical ethernet interface. You can also specify a network
simulator or a module with no input/output ("null"). See the table below for
currently supported values.

ETHDEV: The ethdev value is the name of the network interface on your host
platform. On UNIX machines, you can get the name by running ifconfig. On
Windows machines, you must run niclist to get the name of the ethdev.
Niclist source code is in misc/niclist.c and it is included in Windows
binary releases.

SCRIPT: The script value is optional, and is the name of a script that
is executed after bochs initialize the network interface. You can use
this script to configure this network interface, or enable masquerading.
This is mainly useful for the tun/tap devices that only exist during
Bochs execution. The network interface name is supplied to the script
as first parameter.

BOOTROM: The bootrom value is optional, and is the name of the ROM image
to load. Note that this feature is only implemented for the PCI version of
the NE2000.

The following table shows the available ethernet modules with description, whether the "ethdev" and "script" parameters are used or not and the Bochs version where this module was added.

Table 4-5. Ethernet modules
Module Description ethdev script Bochs version
fbsd FreeBSD / OpenBSD packetmover. Yes No 1.0
linux Linux packetmover - 'root' privileges required, no connection to the host machine. Yes No 1.3
null Null packetmover. All packets are discarded, but logged to a few files. No No 1.0
tap TAP packetmover. Yes Yes 1.4
tuntap TUN/TAP packetmover - see Configuring and using a tuntap network interface. Yes Yes 2.0
vde Virtual Distributed Ethernet packetmover. Yes Yes 2.2
vnet ARP, ping (ICMP-echo), DHCP and read/write TFTP simulation. The virtual host uses 192.168.10.1. DHCP assigns 192.168.10.2 to the guest. The TFTP server uses the 'ethdev' value for the root directory and doesn't overwrite files. Yes, for TFTP Yes, for log file name 2.2
slirp Built-in Slirp support with DHCP / TFTP servers. Adds user mode networking to Bochs - see Using the 'slirp' networking module. The 'script' parameter can be used to set up an alternative IP configuration or additional features. The TFTP server uses the 'ethdev' value for the root directory and doesn't overwrite files. Yes, for TFTP Yes, for Slirp config 2.6.5
socket Connect up to 6 Bochs instances on the same or other machine with external program 'bxhub' (simulating an ethernet hub). It provides the same services as the 'vnet' module and assigns IP addresses like 'slirp' (10.0.2.x) (see Using the 'socket' networking module). Yes, for base UDP port and (optional) the host to connect No 2.6.9
win32 Win32 packetmover - WinPCap driver required. Yes No 1.3

4.3.35. pcipnic

Example:

pcipnic: enabled=1, mac=b0:c4:20:00:00:00, ethmod=vnet

To support the Bochs/Etherboot pseudo-NIC, Bochs must be compiled with the --enable-pnic configure option. It accepts the same syntax (for mac, ethmod, ethdev, script, bootrom) and supports the same networking modules as the NE2000 adapter.

4.3.36. e1000

Example:

e1000: enabled=1, mac=52:54:00:12:34:56, ethmod=slirp, script=slirp.conf

To support the Intel(R) 82540EM Gigabit Ethernet adapter, Bochs must be compiled with the --enable-e1000 configure option. It accepts the same syntax (for mac, ethmod, ethdev, script, bootrom) and supports the same networking modules as the NE2000 adapter.

4.3.37. usb_uhci

Examples:

usb_uhci: enabled=1, port1=mouse, port2=disk:usbstick.img
usb_uhci: enabled=1, port1=hub:7, port2=disk:growing:usbdisk.img
usb_uhci: enabled=1, port2=disk:undoable:usbdisk.img, options2=journal:redo.log
usb_uhci: enabled=1, port2=disk:usbdisk2.img, options2=sect_size:1024
usb_uhci: enabled=1, port2=disk:vvfat:vvfat, options2="debug,speed:full"
usb_uhci: enabled=1, port1=printer:printdata.bin, port2=cdrom:image.iso
usb_uhci: enabled=1, port2=floppy:vvfat:diskette, options2="model:teac"

This option controls the presence of the USB root hub which is a part of the i440FX PCI chipset.

With the portX option you can connect devices to the hub (currently supported: 'mouse', 'tablet', 'keypad', 'disk', 'cdrom', 'floppy, ''hub' and 'printer').

If you connect the mouse or tablet to one of the ports, Bochs forwards the mouse movement data to the USB device instead of the selected mouse type. When connecting the keypad to one of the ports, Bochs forwards the input of the numeric keypad to the USB device instead of the PS/2 keyboard.

To connect a 'flat' mode image as a USB hardisk you can use the 'disk' device with the path to the image separated with a colon. To use other disk image modes similar to ATA disks the syntax 'disk:mode:filename' must be used (see above).

To emulate a USB cdrom you can use the 'cdrom' device name and the path to an ISO image or raw device name also separated with a colon. An option to insert/eject media is available in the runtime configuration.

To emulate a USB floppy you can use the 'floppy' device with the path to the image separated with a colon. To use the VVFAT image mode similar to the legacy floppy the syntax 'floppy:vvfat:directory' must be used (see above). An option to insert/eject media is available in the runtime configuration.

The device name 'hub' connects an external hub with max. 8 ports (default: 4) to the root hub. To specify the number of ports you have to add the value separated with a colon. Connecting devices to the external hub ports is only available in the runtime configuration.

The device 'printer' emulates the HP Deskjet 920C printer. The PCL data is sent to a file specified in bochsrc.txt. The current code appends the PCL code to the file if the file already existed. The output file can be changed at runtime.

The optionsX parameter can be used to assign specific options to the device connected to the corresponding USB port. Currently this feature is used to set the speed reported by device ('low', 'full', 'high' or 'super'). The available speed choices depend on both HC and device. The option 'debug' turns on debug output for the device at connection time. For the USB 'disk' device the optionsX parameter can be used to specify an alternative redolog file (journal) of some image modes. For 'vvfat' mode USB disks the optionsX parameter can be used to specify the disk size (range 128M ... 128G). If the size is not specified, it defaults to 504M. For the USB 'floppy' device the optionsX parameter can be used to specify an alternative device ID to be reported. Currently only the model "teac" is supported (can fix hw detection in some guest OS). The USB floppy also accepts the parameter "write_protected" with valid values 0 and 1 to select the access mode (default is 0).

Note: PCI support must be enabled to use USB UHCI.

4.3.38. usb_ohci

Example:

usb_ohci: enabled=1, port1=printer:printdata.bin

This option controls the presence of the USB OHCI host controller with a 2-port hub. The portX parameter accepts the same device types with the same syntax as the UHCI controller (see the usb_uhci option). The optionsX parameter is also available on OHCI.

4.3.39. usb_ehci

Example:

usb_ehci: enabled=1, port1=tablet, options1="speed:high"

This option controls the presence of the USB EHCI host controller with a 6-port hub. The portX parameter accepts the same device types with the same syntax as the UHCI controller (see the usb_uhci option). The optionsX parameter is also available on EHCI.

4.3.40. usb_xhci

Example:

usb_xhci: enabled=1, port1="disk:usbdisk.img"

This option controls the presence of the USB xHCI host controller with a 4-port hub. The portX parameter accepts the same device types with the same syntax as the UHCI controller (see the usb_uhci option). The optionsX parameter is also available on xHCI. NOTE: port 1 and 2 are USB3 and only support super-speed devices, but port 3 and 4 are USB2 and support speed settings low, full and high.

4.3.41. pcidev

Example:

pcidev: vendor=0xbabe, device=0x2bad

Enables the mapping of a host PCI hardware device within the virtual PCI subsystem of the Bochs x86 emulator. The arguments vendor and device should contain the PCI vendor ID respectively the PCI device ID of the host PCI device you want to map within Bochs.

Note: The PCI device mapping is still in a very early stage of development and thus it is very experimental. This feature requires Linux as a host operating system.

Besides the pcidev config line you will need to load a pcidev kernel module within your Linux host OS. This kernel module is located in the bochs/host/linux/pcidev/ directory.

4.3.42. gdbstub

Example:

gdbstub: enabled=1, port=1234, text_base=0, data_base=0, bss_base=0

Default:

gdbstub: enabled=0

This enables the GDB stub. See Section 8.15.

4.3.43. magic_break

Example:

magic_break: enabled=1

This enables the "magic breakpoint" feature when using the debugger. The useless cpu instruction XCHG BX, BX causes Bochs to enter the debugger mode. This might be useful for software development.

4.3.44. debug_symbols

Example:

debug_symbols: file=mysymbols.sym
debug_symbols: file=mysymbols.sym, offset=0x1000

This loads symbols from the specified file for use in Bochs' internal debugger. Symbols are loaded into global context. This is equivalent to issuing ldsym debugger command at start up.

4.3.45. port_e9_hack

Example:

port_e9_hack: enabled=1

The 0xE9 port doesn't exists in normal ISA architecture. However, we define a convention here, to display on the console of the system running Bochs anything that is written to it. The idea is to provide debug output very early when writing BIOS or OS code for example, without having to bother with setting up a serial port or etc. Reading from port 0xE9 will will return 0xe9 to let you know if the feature is available. Leave this 0 unless you have a reason to use it.

4.3.46. user_plugin

Example:

user_plugin: name=testdev

Load user-defined plugin. This option is available only if Bochs is compiled with plugin support. Maximum 8 different plugins are supported. See the example in the Bochs sources how to write a plugin device.

Notes
[1]

IPS measurements depend on OS and compiler configuration in addition to host processor clock speed.