Re: [Qemu-devel] Win2k mouse

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Hetz Ben Hamo wrote:

> Mike Nordell has send a keyboard/mouse fix for win2k as a guest,
> but I only see keyboard fix in the CVS.

Actually, the fix wasn't specifically for win2k guest. It was a deadlock
that would most probably have occured in any guest OS having both mouse and
keyboard input.

The problem was that (PS/2) mouse input was given priority when QEMU came to
choose between mouse and keyboard interrupts to report to the CPU, but when
the guest was reading I/O port 0x60 the keyboard queue had priority. Imagine
the deadlock when both mouse and keyboard messages were pending. :-)

The easiest way to see this bug in action was by grabbing the mouse and then
alt-tab (or whatever the kbd shortcut for switching to another window is in
your environment) to another window. Voila. Instant guest input lock.


I've got a feeling, though not yet any strong evidence, that since QEMU PC
emulation is yet so incomplete (it's basically like a 386 PC, with a 686
CPU) NT switches to some safety-mode for a lot of stuff. This could
potentially involve a lot of switching between protected mode and v86 mode,
which would slow down the emulation as seen. It's btw not only mouse - try
starting the Task Manager in the guest and watch the CPU pegged while
running it. Close that one and start PerfMon. Add e.g. interrupts/s or DPC
time or... anything. The numbers are off the chart (probably NT can't even
get them, but it might also be they are so insanely high they can't be
trusted), but it's no longer pegging the CPU (you'll notice it's no longer
using all available host CPU).

I'm right now on my way to add some profiling code to QEMU to see what's
going on in this area. While NT as guest behaves like this, just booting it
is a test of patience why it might take some days before I get any real
numbers.

/Mike

Re: [Qemu-devel] Win2k mouse

[Jean-Michel POURE]

> While NT as guest behaves like this, just booting it
> is a test of patience why it might take some days before I get any real
> numbers.

Dear Mike,

Actually, under my Pentium4 1.8 Ghz desktop, QEMU is able to boot Win2k in 90 
seconds (until password prompt) and needs another 30 seconds to display the 
desk. This is fairly fast compared to other emulation softwares.

When using Bochs, I can remember installations lasting 48 hours and a one hour 
startup. Using Qemu, I was able to install Win2k in one hour and a half. 

In the case of Win2k, appying the ne2000 patch and solving the mouse issue 
would be perfect. Then people can start using Win2k and sending bug reports, 
patches and improvements. 

Cheers,
Jean-Michel

Re: [Qemu-devel] Win2k mouse

[Lionel Ulmer]

> In the case of Win2k, appying the ne2000 patch and solving the mouse issue 
> would be perfect. Then people can start using Win2k and sending bug reports, 
> patches and improvements. 

In my case, I still have QEMU segfaulting on me during the second stage
installation.

      Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Win2k mouse

[Brad Campbell]

Lionel Ulmer wrote:
>>In the case of Win2k, appying the ne2000 patch and solving the mouse issue 
>>would be perfect. Then people can start using Win2k and sending bug reports, 
>>patches and improvements. 
> 
> 
> In my case, I still have QEMU segfaulting on me during the second stage
> installation.

Ditto that..

I did get it past there once, but would you belive my hard disk file was 25mb too small and I have 
not been able to get it to work since :p|

Regards,
Brad

Re: [Qemu-devel] Win2k mouse

[Jean-Michel POURE]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le jeudi 15 Avril 2004 11:37, Lionel Ulmer a écrit :
> In my case, I still have QEMU segfaulting on me during the second stage
> installation.

Can you try installing from a legace Win2k CD-ROM (not a temporary local copy 
to disc file), 256 Mb of virtual memory (it crashed with 128). Also, you need 
the latest Qemu CVS version.

My startup line was:
qemu -hda hd.img -cdrom /dev/hdc -m 256 -b d

in a root session (to benefit from network). Works like a charm for me.
Did it work for anyone else?

Cheers,
Jean-Michel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfndLextoHHj2YFMRAojCAKDNBgwdrNJfmzA5gQq+SKXgt6jI1QCffhrx
RgUoHQIISL1irFeJUowjFXI=
=xeaX
-----END PGP SIGNATURE-----

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Jean-Michel POURE wrote:

> Can you try installing from a legace Win2k CD-ROM (not a temporary
> local copy to disc file), 256 Mb of virtual memory (it crashed with 128).

I've installed it with 64MB. OK, some parts of the installation went less
than well (like the emulated CD-ROM wasn't found by the setup - but it later
was when running fail-safe mode).

Hmmm, you say it works just fine with 256MB. I wonder if less RAM might be
due to a segment overrun... (Fabrice has a fix in the pipe).


/Mike

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Lionel Ulmer wrote:

> In my case, I still have QEMU segfaulting on me during the second
> stage installation.

I believe the fix is in the pipe. But to get some more input on something
related; could you first make sure you have target-i386/helper.c from CVS.
Then test searching for "XXX: explain me why W2K hangs" and replace "#if 1"
with "#if 0". There is reason to believe the fixed eip when returning to v86
mode has taken care of the problem that cludge was for.

In addition I can report that doing just that, resetting the segment cache,
allows the ToolStar*Test demo floppy to run as expected. Previously it
had... should we say some problems.


There are still bugs in the VGA code that will totally hang for which I've
mailed Fabrice the patches. Should you want to preempt CVS to see if they
make a difference (they stop QEMU from SEGV), at the beginning of
vga_update_display add the following:

    if (!(s->ar_index & 0x20)) { /* output is disabled */
        printf("VGA: vga_update_display not updating due to display
disabled\n");
        return;
    }


Then in vga_draw_text (sorry, no line numbers since my vga.c doesn't match
yours in that respect), around 90 lines into it just before the cy loop
starts, try the following:

    if (height * width >= CH_ATTR_SIZE)
    {
        printf("TMN: Saving VGA from crashing in vga_draw_text()\n");
        return;
    }


/Mike

Re: [Qemu-devel] Win2k mouse

[Lionel Ulmer]

> Then in vga_draw_text (sorry, no line numbers since my vga.c doesn't match
> yours in that respect), around 90 lines into it just before the cy loop
> starts, try the following:
> 
>     if (height * width >= CH_ATTR_SIZE)
>     {
>         printf("TMN: Saving VGA from crashing in vga_draw_text()\n");
>         return;
>     }

This is the one that saves me :

VGA: vga_update_display not updating due to display disabled
VGA: vga_update_display not updating due to display disabled
TMN: Saving VGA from crashing in vga_draw_text()

Now I start to see the rest of the Win2K second-stage installer. So at least
it helps going a bit further than before.

          Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Win2k mouse

[Lionel Ulmer]

> Now I start to see the rest of the Win2K second-stage installer. So at least
> it helps going a bit further than before.

Well, I spoke a bit too fast : it's still segfaulting, but a bit further
than before, just after the 'Setup is detecting and installing devices on
your computer'.

Trying a second time right now (I only have a P2 333, so it's rather slow).
If it's still crashing, I will test with re-putting the '#if 1' in the
helper.c file to see if it helps).

            Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] Win2k mouse

[Mike Nordell]

Lionel Ulmer wrote:

> > Now I start to see the rest of the Win2K second-stage installer. So at
> > least it helps going a bit further than before.
>
> Well, I spoke a bit too fast : it's still segfaulting, but a bit further
> than before, just after the 'Setup is detecting and installing devices on
> your computer'.

Just for kicks, you might test the following for hw/sb16:

@@ -426,6 +449,7 @@
             dsp->v2x6 = 0;
         else if ((1 == val) && (0 == dsp->v2x6)) {
             dsp->v2x6 = 1;
+            assert(dsp->out_data_len <
sizeof(dsp->out_data)/sizeof(*dsp->out_data));
             dsp->out_data[dsp->out_data_len++] = 0xaa;
         }
         else
@@ -537,6 +561,7 @@
 static IO_READ_PROTO(mixer_read)
 {
     SB16State *dsp = opaque;
+     assert(dsp->mixer_nreg <
sizeof(dsp->mixer_regs)/sizeof(*dsp->mixer_regs));
     return dsp->mixer_regs[dsp->mixer_nreg];
 }


I'm right now in the debugger after an attempted read from memory the SB16
emulator has no business probing.

Right after this, the gfx got really screwy, starting to display vertical
white lines over the setup dialog, why I think it's a fair bet guest kernel
memory has been overwritten by something. Judging by these accesses, I quite
obviously suspect some other device emulation code. I'll add another bunch
of asserts all over the place, but considering it takes me around 2-3 hours
to reach this point (starting from an image where the first phase of the
setup, copying files to target disk, has already completed), don't expect
any earth-shattering revelations anytime soon.


Does anyone know SB16 h/w enough to say what would be the right behaviour
here:

- To limit mixer_nreg in mixer_write_indexb to ?
- To return 0xff (or anything else) from mixer_read if mixer_nreg is OOB?
- To extend mixer_nreg to 256 bytes?
- To, just for kicks, stream n chunks of m bytes from /dev/random to an
equally random address in the QEMU process' memory? Just to see what
happens. :-)


/Mike - looking for devices that need some TLC with a 2x4

Re: [Qemu-devel] Win2k mouse

[malc]

On Fri, 16 Apr 2004, Mike Nordell wrote:

> Lionel Ulmer wrote:
>
> > > Now I start to see the rest of the Win2K second-stage installer. So at
> > > least it helps going a bit further than before.
> >
> > Well, I spoke a bit too fast : it's still segfaulting, but a bit further
> > than before, just after the 'Setup is detecting and installing devices on
> > your computer'.
>
> Just for kicks, you might test the following for hw/sb16:
>
> @@ -426,6 +449,7 @@
>              dsp->v2x6 = 0;
>          else if ((1 == val) && (0 == dsp->v2x6)) {
>              dsp->v2x6 = 1;
> +            assert(dsp->out_data_len <
> sizeof(dsp->out_data)/sizeof(*dsp->out_data));
>              dsp->out_data[dsp->out_data_len++] = 0xaa;
>          }
>          else
> @@ -537,6 +561,7 @@
>  static IO_READ_PROTO(mixer_read)
>  {
>      SB16State *dsp = opaque;
> +     assert(dsp->mixer_nreg <
> sizeof(dsp->mixer_regs)/sizeof(*dsp->mixer_regs));
>      return dsp->mixer_regs[dsp->mixer_nreg];
>  }
>
>
> I'm right now in the debugger after an attempted read from memory the SB16
> emulator has no business probing.
>
> Right after this, the gfx got really screwy, starting to display vertical
> white lines over the setup dialog, why I think it's a fair bet guest kernel
> memory has been overwritten by something. Judging by these accesses, I quite
> obviously suspect some other device emulation code. I'll add another bunch
> of asserts all over the place, but considering it takes me around 2-3 hours
> to reach this point (starting from an image where the first phase of the
> setup, copying files to target disk, has already completed), don't expect
> any earth-shattering revelations anytime soon.
>
>
> Does anyone know SB16 h/w enough to say what would be the right behaviour
> here:

I have used http://www.doc.ic.ac.uk/~ih/doc/sound/sblast09/ as a
reference. Only 131 mixer registers are documented there.

>
> - To limit mixer_nreg in mixer_write_indexb to ?
> - To return 0xff (or anything else) from mixer_read if mixer_nreg is OOB?
> - To extend mixer_nreg to 256 bytes?
> - To, just for kicks, stream n chunks of m bytes from /dev/random to an
> equally random address in the QEMU process' memory? Just to see what
> happens. :-)

My vote goes for the latter.

-- 
mailto:malc@pulsesoft.com

[Qemu-devel] sound issue

[Hetz Ben Hamo]

Hi,

Any chance you could "port" the SB16 code from Bochs? 

Thanks,
Hetz

> I have used http://www.doc.ic.ac.uk/~ih/doc/sound/sblast09/ as a
> reference. Only 131 mixer registers are documented there.

[Qemu-devel] Win2k mouse

[Jean-Michel POURE]

Dear all,

I am trying to understand why Win2k mouse is so slow. Is this because Win2k 
grabs the mouse 20 times a second and Qemu should perform more IPS?

Is there any setting (including in Qemu source code) to work around this 
issue? Do you plan to add some runtime parameter to Qemu in a near future?

Cheers,
Jean-Michel

Re: [Qemu-devel] Win2k mouse

[Hetz Ben Hamo]

Hi,

According to this: 
http://savannah.nongnu.org/cgi-bin/viewcvs/qemu/qemu/Changelog.diff?r1=1.39&r2=1.40

Mike Nordell has send a keyboard/mouse fix for win2k as a guest, but I only 
see keyboard fix in the CVS.

Mike, did u fix the mouse behavior also?

Thanks,
Hetz

On Wednesday 14 April 2004 10:49, Jean-Michel POURE wrote:
> Dear all,
>
> I am trying to understand why Win2k mouse is so slow. Is this because Win2k
> grabs the mouse 20 times a second and Qemu should perform more IPS?
>
> Is there any setting (including in Qemu source code) to work around this
> issue? Do you plan to add some runtime parameter to Qemu in a near future?
>
> Cheers,
> Jean-Michel
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Win2k mouse

[Fabrice Bellard]

Jean-Michel POURE wrote:
> Dear all,
> 
> I am trying to understand why Win2k mouse is so slow. Is this because Win2k 
> grabs the mouse 20 times a second and Qemu should perform more IPS?
> 
> Is there any setting (including in Qemu source code) to work around this 
> issue? Do you plan to add some runtime parameter to Qemu in a near future?

The mouse problem in win2k is a bug, and I have currently not 
investigated the issue.

Fabrice.