qemu monitor

[srg]

Hi

I'm just trying qemu and it as great potential, but how do I access the monitor. I've got the latest Windows built and it's supposed to support it, but where?

thanks
srg

[df]

ctrl-shift f1 for main screen
ctrl-shift f2 for monitor

the monitor lets you change floppy disks etc images blah.

[srg]

ctrl-shift f1 for main screen
ctrl-shift f2 for monitor

the monitor lets you change floppy disks etc images blah.

When I did that all it did was turn mouse grabbing on and off, is there supposed to be two windows come up? it's just that on my command prompt, after exetucing it, the command prompt comes stright back, so I can't enter any of the monitor commands into that, there do I enter the monitor commands?

srg

[df]

no it just swaps screens for the monitor.

works for me. ctrl-shift-f2 to get to monitor, ctr-shift-f1 to get back.

the timing on this here p3-450, i have to press it LOTS or hold it down for a few seconds and it will kick over.

[srg]

right, the one that uses the installer doesn't have monitor support. I downloaded again this time from the proper site (no installer and this time it works, well infact the monitor is in a seperate window.

Anyway, in your oppinion what do you think of this compaied to bochs?

Having to use floppy images is a pain the the A**.

srg

[df]

the fact qemu gives you a valid PCI bios32 makes it far superiour in my opinion.

all it needs is a better front end

qemu leaves bochs for dead imo and its only getting better.

[srg]

Is it possible in the windows version of qemu to use the floppy drive rather than an image (creating images is annoying).

I know it can be done in Linux with /dev/fd0 but what about windows?

srg

[df]

dunno. i always use images. all my tools work with images. i never use 'real' hardware.

[srg]

dunno. i always use images. all my tools work with images. i never use 'real' hardware.

I only use simulators because of their debuggers and monitors, otherwise I use variouse configurations of real hardware (I have 2 machines - a 386 and a 486 - dedicated to it).

qemu will go into the testing arsena, it's faster than bochs and I like monitor but Bochs is more flexible, VMWare is faster still (i have all three of them) but has no debugger. VMWare is also more realistic. Qemu is like a cross between the other two, it really has promise.

srg

[Dreamsmith]

I would like to use qemu, but it just hangs when trying to boot my OS (which boots perfectly fine under Bochs and on all the real hardware I've tried it on). So for me, it's still in the "nice idea but definately still needs work before being usable" department.

[df]

hmm thats odd. i have installed beos under qemu, and tested a load of disk images and they all booted fine.

as long as you tell qemu your image is a floppy and boot with floppy, otherwise it will get confused that its a hard disk.

i have vmware workstation since 2.0, and ill use that if i want cycle accuracy etc. but for booting a floppy image, qemu does just fine.

[Curufir]

Qemu has, in the past, given me a few problems that looked like they originated from code using unreal mode. Dunno if that's fixed, but it was definitely a Qemu problem (Hardware/Bochs worked fine).

[Dreamsmith]

Yes, my own problems with QEMU stem from it's buggy implementation of Virtual-8086 mode. Specifically, it causes spurious Page Fault exceptions if the V86 task's TSS is located in supervisor space when it's supposed to generate a General Protection exception. It appears the simulator doesn't switch to supervisor mode before attempting to address its own TSS (CR2 points to the 103rd byte of the V86 task's TSS), which causes it to Page Fault instead of GPFing. Real hardware and Bochs switch to supervisor mode first, or perhaps they simply don't do protection checks in this circumstance, but either way they successfully read the TSS for the values they need to generate the GPF, and thus proceed normally instead of page faulting. Until QEMU starts to work like real processors do under these circumstances, my OS is unbootable under QEMU. Well, I can work around the problem by marking the page in question user accessible, but that's a gaping security hole I'd rather not leave lying around in my code. When I do do this, though, everything else works fine, so this appears to be the only bug preventing me from using QEMU. I've reported it, so hopefully they'll fix it sometime soon...

[srg]

Yes, my own problems with QEMU stem from it's buggy implementation of Virtual-8086 mode. Specifically, it causes spurious Page Fault exceptions if the V86 task's TSS is located in supervisor space when it's supposed to generate a General Protection exception. It appears the simulator doesn't switch to supervisor mode before attempting to address its own TSS (CR2 points to the 103rd byte of the V86 task's TSS), which causes it to Page Fault instead of GPFing. Real hardware and Bochs switch to supervisor mode first, or perhaps they simply don't do protection checks in this circumstance, but either way they successfully read the TSS for the values they need to generate the GPF, and thus proceed normally instead of page faulting. Until QEMU starts to work like real processors do under these circumstances, my OS is unbootable under QEMU. Well, I can work around the problem by marking the page in question user accessible, but that's a gaping security hole I'd rather not leave lying around in my code. When I do do this, though, everything else works fine, so this appears to be the only bug preventing me from using QEMU. I've reported it, so hopefully they'll fix it sometime soon...

I'm guessing v86 mode is important to your os, are you basing yours arround it or are you using it for video BIOS or something?

srg

[df]

myself, i dont touch v86 so havnt seen these bugs.

dont forget, qemu is 0.6, bochs is several years old and 2.1.1. they are doing a lot of work on qemu and to me, it already shows more promise than bochs.