Emulator library for OS testing

[madanra]

It would be nice to be able to run automated tests for OS development.

Are there any emulator libraries that would be suitable for this?

I had considered writing a wrapper around Bochs, but it doesn't seem like there's a good way of eg. simulating a disk read failure, as Bochs emulates the whole system, so there's no way to hook into what happens when a disk read is requested.

[BrightLight]

Why would you want to emulate a failure? Besides, it's actually easier to cause a failure than a success!

[Roman]

Why would you want to emulate a failure?

To test error-handling.

[BrightLight]

Why would you want to emulate a failure?

To test error-handling.

But making a failure is actually too easy! It's actually easier than getting something to work right

[SpyderTL]

He wants to run his OS on a virtual machine, like BOCHS, and have the virtual machine "emulate" a hardware error, so that he can test his OS and make sure it handles the hardware error properly.

[Combuster]

Why not use bochs, set a breakpoint, and mess stuff up from the debugger console?

[madanra]

Sure, Bochs is fine for manual testing. I'm not sure that process can be automated, though.

[Combuster]

No automation?

Code: Select all

$ cat cmds.txt
s 1000
regs
quit

$ bochsdbg64 -q -f bochsrc.conf < cmds.txt
(...)
Next at t=0
(0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
<bochs:1> s 1000
00000000025i[MEM0 ] allocate_block: block=0x0 used 0x1 of 0x20
Next at t=1000
(0) [0x00000000000f05e2] f000:05e2 (unk. ctxt): push bx                   ; 53
<bochs:2> regs
rax: 0x00000000_00000171 rcx: 0x00000000_00000000
rdx: 0x00000000_00000000 rbx: 0x00000000_0000fff8
rsp: 0x00000000_0000ffc8 rbp: 0x00000000_0000ffc8
rsi: 0x00000000_00000000 rdi: 0x00000000_00000500
r8 : 0x00000000_00000000 r9 : 0x00000000_00000000
r10: 0x00000000_00000000 r11: 0x00000000_00000000
r12: 0x00000000_00000000 r13: 0x00000000_00000000
r14: 0x00000000_00000000 r15: 0x00000000_00000000
rip: 0x00000000_000005e2
eflags 0x00000006: id vip vif ac vm rf nt IOPL=0 of df if tf sf zf af PF cf
<bochs:3> quit
00000001000i[     ] dbg: Quit
(...)

$

[alexfru]

This is a common testability problem. A common solution to it is to introduce a layer between your code and the underlying stuff (in your case, accesses to BIOS functions, I/O ports, perhaps some other things). This layer can simulate errors either in a controllable way (it has some configurable logic of when to simulate an error and your tests would use it) or random way (it just randomly simulates errors with some low probability, all by itself).

[madanra]

@Combuster:
Hmm - I would need to find a way to capture the screen contents in an automated fashion as well, which could be tricky when the test is running on a headless server. I'll look into it...

@alexfru:
When I get on to higher level stuff, that will certainly be possible. But there will always be a few things where that's not possible - one extreme example would be a bootloader, where there's not space for an extra layer.

[Combuster]

It's too simple. Just add more stock unix plumbing. Even stdout and stderr are nicely separated in what they render

[madanra]

But stdout/stderr only contain the terminal output, not what's on the guest's screen? Unless you're using the 'term' output library, which is incompatible with debug mode in Bochs.

[Combuster]

<bochs:1> help writemem
writemem <filename> <laddr> <len> - dump 'len' bytes of virtual memory starting from the linear address 'laddr' into the file

Tested and also works on video memory.

[alexfru]

When I get on to higher level stuff, that will certainly be possible. But there will always be a few things where that's not possible - one extreme example would be a bootloader, where there's not space for an extra layer.

Sure, there will always be tight places limiting the spectrum of available methods. If your 1st stage bootloader fits into 512 bytes, indeed, there isn't much room for extra stuff. But you can create several variations of it with hardcoded errors and you can test it manually or semi-manually (depending on what information you can extract from the environment, e.g. indications of successful or failed boot).

[madanra]

<bochs:1> help writemem
writemem <filename> <laddr> <len> - dump 'len' bytes of virtual memory starting from the linear address 'laddr' into the file

Tested and also works on video memory.

Fair enough

Now to work out how to reliably determine when the code is finished...