qemu discuss - Feb 2007 - PATCH: Whole kqemu module can be natively built on Solaris now

( ... not the kqemu-wrapper alone [and then linked against foreign built object
files, as until recently]. )
Only Makefiles needed to be "ported".
No real porting.
But more testing was required, than one might have expected (#0._gld_vs._ld
&& #1._mcmodel=kernel vs. -fpic)

"gdiff -Nurb" against http://qemu.com/kqemu-1.3.0pre11.tar.gz :
http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__osol20070214.gdiff.bz2

Same gdiff, but without Eric Lowe''s CDDL licensed kqemu-solaris wrapper
code :
http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__osol20070214_WithoutEricLowesWRAPPER__kqemu-solaris.c__.gdiff.bz2

OPEN kqemu accelerator FULL src && bins :
http://opensolaris.org/os/project/qemu/downloads/kqemu-1.3.0pre11__sol10FCSplus_20070214_src_and_bins.tar.bz2

Juergen Keil''s latest patch (enabling kqemu on old Sol10FCS based
hosts) is embedded and compiled in.


Thanks for the steadily increasing community involvement, testing and comments.

Speacial thanks to Juergen Keil, Ben Taylor and Eric Lowe.

p.s. SUNWqemu 0.9.0 sparc and x86/x64 (with Sittichai''s TAP patch) will
be released on 20070218.

Thanks.

qemu-discuss at opensolaris.org

btw: kqemu may not be a wonder pill.
But it does increase performance dramatically in _certain_ scenarios.
Please start by reading the docs: http://qemu.com/kqemu-tech.html 
http://qemu.com/kqemu-doc.html  http://qemu.com/kqemu-changelog.html

I tried  kqemu mentioned above on Solaris 10 update 1 with qemu 0.9.0.
It crashed after running Windows XP for a while.
--
This message posted from opensolaris.org

Hello,
> I tried  kqemu mentioned above on Solaris 10 update 1 with qemu 0.9.0.
> It crashed after running Windows XP for a while.

"after a while" is actually a success.
Core dump please (or dbx''s dis output)?

Are you referring to kqemu user-mode or both user- and kernel mode?

Another leap: I get marTux_0.2__amd64 OpenSolaris fully booted with those two
modes active (-kernel-kqemu).
That wasn''t posssible in the past - with the previous module. It would
always crash at the point during boot where the kernel prints who he is.
(Test performed on U20 host which is running hdd install of marTux_0.2_amd64).
Question is, if that positive change has to do with the fact, that the previous
core-kqemu-module had been version pre09 and is now pre11.
Or - on the other hand - that we can compile the object files natively on
Solaris now.
The marTux_0.2 guest only crashes (forced guest reset), _after_ Xorg is already
running, when you click the left mouse button for the first time (under twm or
fvwm2 - wm doesn''t matter).
It''s damn fast with -kernel-kqemu (both the 32x32x32 case, but even the
64x64x64 case, which had been rather slow previously, due to
qemu-system-x86_64''s bigger workload - compared to bin/qemu).

###

General side note: Win9x would very well run with -kernel-kqemu (just as
WinNT5.x does), if there wasn''t Microsoft''s undocumented code
in Win4''s (DOS386.EXE [original name from 1993 alpha]''s)
ios.vxd, which is thought to prevent the Win4.x GUI from booting on MS-DOs5.x or
6.x, among other things.
ios.vxd expects certain undocumented data structures (partially mentioned in
Win9x''s DDK header files) to be present at undocumented real mode
addresses. If they aren''t, the boot process leaves v86 mode,
protected32 and protected16 mode and falls back to realmode: And prints that
dumb "Windows protection error" message.
There are more things under certain places which prevent Win95/98/SE/ME from
booting the GUI on old MS-DOS5.x - but this one is indeed KQEMU-relevant.

See http://members.ozemail.com.au/~geoffch/samples/dos/dosbook/crtdrvr.htm
""New code in the DOS 7 kernel (previously MSDOS.SYS but now bound
into IO.SYS) makes int 21h function 31h unsafe to use during device driver
initialisation. This affects any device driver produced by linking the CRTDRVR
library with code for a DOS program that terminates and stays resident.

Certain VxDs in Windows 95 need to know whether any DOS device drivers and
programs have used resources of interest. For instance, have any hooked int 13h
or a hardware interrupt?
[...]
Interestingly, VxDs do not have access to this record via the int 21h function
1690h interface. The IOS VxD finds the record by knowing that the address is
kept as the dword at offset 1328h in the DOS kernel?s data segment. The layout
and location of this TSR record appear to be undocumented.""

I''ve been single-stepping through Win4.x boot half a year long
(netto!).
That idiotic biderectional io.sys <<--->> ios.vxd double-checking is
a wonder (I mean, that it works at all on most cumputers).
But smallest changes of register content (i.e. leaving certain loops premature)
make it fail (in my tests with SoftICE, back then).
Fast >= 400 MHz AMD cpu''s result in the same problem (under 4.00.950
to C).
And quemu''s "-kernel-kqemu" is just yet another example. So
it doesn''t say anything about kqemu''s correctness and
reliability. It must be possible to fix "-kernel-kqemu" Win9x guest
support.

Just let us request the 16bit-MS-DOS 7.00/10/10A or 8.00 sources from Microsoft.

Following are stack traces.
ide_read_dma_cb+0xf(9d1f854, 0, ce3773a0, ce377000, 80446c8, ce366089)
qcow_aio_read_cb+0x209(9d1f8b0, 0, 80448b8, 806bc81, 9b42c78, 0)
qemu_aio_poll+0x6c(9b84f78, 4, 0, 0, 0, 0)
main_loop_wait+0x1e1(0, 9d21390, 80448d8, 806b4a5)
main_loop+0xd5(0, 0, 0, 0, 0, 0)
main+0x15d7(11, 8047bb8, 8047c00)
_start+0x5d(11, 8047cc4, 8047cfb, 8047d09, 8047d0e, 8047d12)

With -kernel-kqemu:

And without -kernel-kqemu:
ide_write_dma_cb+0xf(9d1f98c, ffffffea, ce3773a0, ce377000, 80446d8, ce365fa0)
qcow_aio_write_cb+0x100(9b98268, ffffffea, 80448c8, 806bc81, 9b42c78, 0)
qemu_aio_poll+0x6c(d1228, 4, 0, 0, 0, 0)
main_loop_wait+0x1e1(0, 0, 0, 0)
main_loop+0xd5(0, 0, 0, 0, 0, 0)
main+0x15d7(10, 8047bc8, 8047c0c)
_start+0x5d(10, 8047cd0, 8047d07, 8047d0c, 8047d10, 8047d15)
--
This message posted from opensolaris.org

The image is converted from raw to qcow2 using qemu-img  with compression
option.
--
This message posted from opensolaris.org

Another core without -kernel-kqemu.
This time with gdb:

(gdb) bt
#0  ide_write_dma_cb (opaque=0x9d1f9c4, ret=-22)
    at /usr1/home/sitchai/QEMU/qemu-0.9.0/hw/ide.c:832
#1  0x0808b6cc in qcow_aio_write_cb (opaque=0x9b96860, ret=-22)
    at /usr1/home/sitchai/QEMU/qemu-0.9.0/block-qcow2.c:947
#2  0x08077738 in qemu_aio_poll ()
    at /usr1/home/sitchai/QEMU/qemu-0.9.0/block-raw.c:244
#3  0x0806bd05 in main_loop_wait (timeout=1)
    at /usr1/home/sitchai/QEMU/qemu-0.9.0/vl.c:6072
#4  0x0806bee9 in main_loop () at /usr1/home/sitchai/QEMU/qemu-0.9.0/vl.c:6153
#5  0x0806d567 in main (argc=16, argv=0x8047b98)
    at /usr1/home/sitchai/QEMU/qemu-0.9.0/vl.c:7417

 **Code    at /usr1/home/sitchai/QEMU/qemu-0.9.0/hw/ide.c:832
static void ide_write_dma_cb(void *opaque, int ret)
{
    BMDMAState *bm = opaque;
    IDEState *s = bm->ide_if;
    int n;
    int64_t sector_num;

    n = s->io_buffer_size >> 9;  <====== line 832
    sector_num = ide_get_sector(s);
    if (n > 0) {
        sector_num += n;
        ide_set_sector(s, sector_num);
        s->nsector -= n;
    }
...

 **Code around  /usr1/home/sitchai/QEMU/qemu-0.9.0/block-qcow2.c:947
...
    if (acb->nb_sectors == 0) {
        /* request completed */
        acb->common.cb(acb->common.opaque, 0); <============ line 947
        qemu_aio_release(acb);
        return;
    }
...
--
This message posted from opensolaris.org

After enable debugging in hw/ide.c I found out there is always a call to
aio_cancel just before
the crash. 


...
aio_write: sector_num=300079 n=1
aio_write: sector_num=2075191 n=8
aio_cancel
aio_write: sector_num=2744079 n=8
aio_write: sector_num=2744615 n=8
aio_read: sector_num=3078839 n=8
Segmentation Fault (core dumped)
...
--
This message posted from opensolaris.org