Re: [Qemu-devel] qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates...

[Juergen Lock]

In article <address@hidden> you write:
>Juergen Lock wrote:
>> Hi!
>>
>>  I've been playing with qemu svn on FreeBSD again (new experimental
>> emulators/qemu-devel port update here:
>>      http://people.freebsd.org/~nox/qemu/qemu-devel-20080921.patch
>> ), and want to note a few things:
>>   
>
>Are all of these things regressions and if so, have you bisected?

The screen update thing probably is (at least I don't remember seeing it
before), slow usb certainly, -vmwarevga I'm not so sure.  The slow usb
I've now found starts with r5050, before (r5049 and earlier) I get ~500 KB/s
with emulated disk: and net: and ~1 MB/s host: (a cardreader) in this guest,
and with r5050 and after 30-40 KB/s with disk: and net: and ~230 KB/s from
the cardreader (actually with r5050 I only got disk: working, this was
fixed in r5070.)  I also since found out that not all guests are affected,
a FreeBSD 7.1-BETA-i386-livefs.iso gets normal throughput with the current
code, actually even more that the Linux guests before r5050 (about 2 MB/s
from disk: and 1.4 MB/s from the cardreader, net: didnt get packets thru
at least with the default settings, looks like it doesn't get detected
properly:

..
cdce0: <QEMU RNDIS/QEMU USB Network Device, class 2/0, rev 2.00/0.00, addr 2> 
on uhub0
cdce0: could not find data bulk in
device_attach: cdce0 attach returned 6
cdce0: <QEMU RNDIS/QEMU USB Network Device, class 2/0, rev 2.00/0.00, addr 2> 
on uhub0
cdce0: faking MAC address
cdce0: WARNING: using obsoleted IFF_NEEDSGIANT flag
cdce0: bpf attached
cdce0: Ethernet address: 2a:00:00:00:00:00

 I also found another problem with usb: looks like when usb_add adds a
device as Device 0.0, Linux guests don't detect it, so sometimes while
testing I had to add devices multiple times.

 And, I found an issue with the new compatfd code on FreeBSD 6.3, looks
like the default threading libs on there (libkse) cause signals to be
delivered to the wrong thread at least when running with kqemu, forcing
libthr to be used instead (the new threading lib) seemed to fix that issue.

 More later...
        Juergen

>>  1. usb is still absymally slow, especially emulated disks (disk:imagefile)
>> and nics, both read/receive at about 30 KBytes/s here.  Is anyone working
>> on this?  I also got a report that its slow on Linux hosts too, so this
>> problem doesn't appear to be FreeBSD specific...
>>
>>  2. -vmwarevga _seems_ to be less broken when run with 16 bpp, only 24
>> bpp seems to get the fifo errors that I posted about last time:
>>      http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00893.html
>> (maybe also the patch I posted there is only needed when running the guest
>> with 24 bpp.)  vmmouse seems to be broken too tho, the guest acts as if
>> the mouse is stuck in the bottom right corner.  (maybe I didn't actually
>> test this the last time, or it has something to do with the newer guest
>> that I used this time which also has a newer xorg version among other
>> things,
>>      sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso
>> announcement including mirror list is here:
>>      http://sidux.com/Article450.html
>> )  The guest xorg crashes with -kernel-kqemu also still happen.
>>
>>  Oh and that guest tries to use vmmouse by default if run with
>> -vmwarevga, to disable it you can boot to runlevel 3 (add a 3 to the
>> grub line), su, change vmmouse to mouse in /etc/X11/xorg.conf, then do
>> init 5 to start X.
>>
>>  3. The screen update problem I mentioned seems to be intermittent,
>> sometimes I see it, sometimes not, and its also possible it only affects
>> the emulated vga console (vga=0 with linux guests.)  Sometimes when I see
>> it there are also partwise screen updates, like I see only some of the
>> lines scrolling.  Whenever it happens, moving the mouse over another
>> window fixes it for a few seconds, until it happens again.  Oh and the
>> guest keeps running all the time, only the screen doesn't update correctly
>> when it happens...
>>
>>  4. There's one good news: completion in the monitor is back to working
>> order! :)  (I suspect because of the qemu_strdup fix.)
>>
>>  Thanx,
>>      Juergen