ffc722f4e8
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
|
||
|---|---|---|
| .github/workflows | ||
| bochs | ||
| bochs-performance | ||
| bochs-testing | ||
| .gitattributes | ||
| .gitignore | ||
| LICENSE | ||
| README.md | ||
Welcome to the Bochs IA-32 Emulator Project
Bochs is a portable IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS.
Bochs can be compiled to emulate many different x86 CPUs, from early 386 to the most recent (sometimes even pre-market) x86-64 Intel and AMD processors.
Bochs is capable of running most Operating Systems inside the emulation including Linux, DOS or Microsoft Windows.
Bochs provides many different modes of operation, in support of a wide variety of use cases. The 'typical' use of bochs is to provide complete x86 PC emulation, including the x86 processor, hardware devices, and memory. This allows you to run OS's and software within the emulator on your workstation, much like you have a machine inside of a machine. For instance, let's say your workstation is a Unix/X11 workstation, but you want to run Win'95 applications. Bochs will allow you to run Win 95 and associated software on your Unix/X11 workstation, displaying a window on your workstation, simulating a monitor on a PC.
Bochs Approach
Bochs is an emulator - not virtualization software. It is portable across many architectures: x86, ARM, MIPS, etc. This means it must be able to emulate every CPU instruction.
This distinguishes Bochs from virtualization solutions like e.g. VirtualBox, VMWare, etc. Those projects provide a nice user experience and fast performance, at the cost of hardware constraints, some non-determinism and some necessary hacks to get programs working.
Bochs' emulation provides a controlled, accurate execution environment, at the cost of speed/performance. This can be advantageous in some situations, for example:
- When developing an operating system or bootloader
- When dealing with very old, mission-critical software
- When reverse-engineering system-level code
For more information, see the intro section in the user guide.
Installing
You can download Bochs from the project page on SourceForge. See the CHANGES file for details on the most recent releases.
Usage
See the documentation.
Contributing
To get started, see Bochs Developer Guide.
We currently need help with the below tasks. To help with one of these tasks, please contact Volker Ruppert or Stanislav Shwartsman.
Bug Reports
Mouse, interrupt controller, timer, IDE controller, network card, keyboard, VGA... Most of our bug reports and feature requests are due to incomplete C++ models of the various PC devices. To improve this, we need PC Hardware Gurus who know where to find the specs for this stuff and improve the hardware models for Bochs. Working on models is a fun way to learn how things work, and unlike designing a real hard disk, you can test out your changes on a real operating system immediately!
Disk Images
Our collection of disk images is getting out of date. It would be great to have small or large images of a variety of free operating systems.
Documentation
Adding installation help and other useful information into the docs.
Papers/Presentations
- Bochs was presented at ISCA-35 in Beijing, China at "The 1st Workshop on Architectural and Microarchitectural Support for Binary Translation" by a paper "Virtualization without direct execution - designing a portable VM".
Authors
Bochs was originally written by Kevin Lawton and is currently maintained by this project.