existing "iolight timer" code in the hard drive code. If an LED is registered
with the "auto-off" flag, the device only needs to turn on the LED to indicate
data transfer. The LED timer in the gui code turns it off after 0.5 seconds if
it is not actived by another transfer. Added this feature to all network
devices.
- TODO #1: implement this feature in the USB host controllers
- TODO #2: the unused timer in the hard drive code could be used for the
emulation of seek functions
- IO intercept is not implemented yet
- MSR intercept is not implemented yet
VMX:
Fixed Bochs PANIC crash when doing I/O access crossing VMX I/O permission bitmaps.
This can happen because access_physical_read and access_physical_write cannot access memory cross 4K boundary.
I am merging the code in order to start making shortcuts between VMX emulation and SVM emulation.
Of course SVM emulation is incomplete, completely untested and not expected to work.
But someone could already take a look one the code and give some suggestions.
Also looking for anybody with existing SVM kernels - as simple as possible - for testing.
Status:
- exceptions intercept is not implemented yet
- IO intercept is not implemented yet
- MSR intercept is not implemented yet
- virtual interrupts are not implemented yet
- CPUID is not implemented yet
No advanced SVM featurez planned - I am implementing the very basic 'Pacifica' document from 2005 using QEMU code as reference.
directly while parsing the bochsrc or command line. If plugin support is enabled,
the option could load all optional plugins, not only the ones supported before.
NOTE #1: The old option had all plugins enabled by default and gave the user
a chance to diable them. Now the plugins are only loaded if they
appear in the config line and they are set to "1".
NOTE #2: Loading a plugin that is controlled by a bochsrc option is possible,
but it currently leads to a panic, since the load command is still
present in devices.cc.
NOTE #3: The plugin init code creates the device object and registers the
optional plugin device. As an option, it can create config parameters
and register an option parser. The device init, register state and
reset is still handled in devices.cc, but in the order the devices
have been loaded with the plugin control.
NOTE #4: If plugin support is disabled, the plugin control only accepts the
devices listed in plugin.cc.
- plugin init of core plugins now fails if they are not loaded with the expected
type. For core plugins the load order is important and they cannot be handled
with the chained devices list (used for optional and user plugins).
- some additions for calling config.cc functions from a plugin device
- added plugin unload function and improved load function
- use new function in bx_unload_plugins()
- new macro BX_UNREGISTER_DEVICE_DEVMODEL for future enhancements
plugins is implemented in bochsrc, these functions can be used to install
additional options from the devices code. Then the whole init / parse / save
code for this device can be moved from config.cc to the device plugin.
turned off. Removed workaround code from devices.cc.
- removed 'pci_ide' plugin from the optional plugin control, since it depends
on the presence of 'pci' and 'harddrv'.
- define types for plugin init/fini functions
- use 'pci_rom_size - 1' as the mask for the offset address
- ne2k: memory handlers must be disabled if compiled without PCI support
- svga_cirrus: check for the PCI ROM size to make VBE work correctly
- added BX_INFO to the mem write handlers
For now it returns a flag that indicated that the device can receive data
from the eth module and flags for the device speed. TODO: Use this callback
in the eth modules before sending data to the device.
