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

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

[Juergen Lock]

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:

 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

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

[Anthony Liguori]

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?

Regards,

Anthony Liguori

>  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
>
>
>   

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

[Juergen Lock]

In article <48D7BA2F.0@codemonkey.ws> 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

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

[Matt]

On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> 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:

Hi.  I've built an updated port with your patch and it compiles fine
and runs my WinXP guests well.  But, the qemu process consumes 100% of
one CPU core on the host the whole time it is running, regardless of
what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
guests run with bridged networking and full kernel kqemu accel
enabled.

Thank you for the continued work on this port!

Matt

[Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Juergen Lock]

In article <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com> you write:
>On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> 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:
>
>Hi.  I've built an updated port with your patch and it compiles fine
>and runs my WinXP guests well.  But, the qemu process consumes 100% of
>one CPU core on the host the whole time it is running, regardless of
>what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
>guests run with bridged networking and full kernel kqemu accel
>enabled.
>
Hmm.  And you didn't see this with the version in ports?  Have you
checked if this is related to kqemu? (try without -kernel-kqemu and
also with -no-kqemu.)  Also, which threading libs and scheduler are you
using?  There seems to be an issue with kse, tho I doubt you are using
that on 7-stable...

 Here is another experimental update that forces -lthr on 6.x, and
also updates to qemu svn r5313:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch

>Thank you for the continued work on this port!

 You're welcome! :)
	Juergen

[Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Matt]

On Wed, Sep 24, 2008 at 5:10 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>
> In article <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com> you write:
> >On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> 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:
> >
> >Hi.  I've built an updated port with your patch and it compiles fine
> >and runs my WinXP guests well.  But, the qemu process consumes 100% of
> >one CPU core on the host the whole time it is running, regardless of
> >what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
> >guests run with bridged networking and full kernel kqemu accel
> >enabled.
> >
> Hmm.  And you didn't see this with the version in ports?  Have you
> checked if this is related to kqemu? (try without -kernel-kqemu and
> also with -no-kqemu.)  Also, which threading libs and scheduler are you
> using?  There seems to be an issue with kse, tho I doubt you are using
> that on 7-stable...

It does appear that this continual CPU-usage was kqemu-related.  When
booting the guest with the "-no-kqemu" option, the CPU usage on the
host was as expected and tracked with the usage in the guest.  Any
level (user or user + kernel) of kqemu accel seemed to trigger the
host to consume 100% CPU regardless of guest activity.

I use the ULE scheduler and libthr threading library.  See console output below.

]$ sysctl kern.sched.name
kern.sched.name: ULE

$ ldd /usr/local/bin/qemu
/usr/local/bin/qemu:
        libm.so.5 => /lib/libm.so.5 (0x101ad000)
        libz.so.4 => /lib/libz.so.4 (0x101c2000)
        libgnutls.so.26 => /usr/local/lib/libgnutls.so.26 (0x101d4000)
        libpcap.so.5 => /lib/libpcap.so.5 (0x1027b000)
        libutil.so.7 => /lib/libutil.so.7 (0x102a2000)
        libSDL-1.2.so.11 => /usr/local/lib/libSDL-1.2.so.11 (0x102b0000)
        libncurses.so.7 => /lib/libncurses.so.7 (0x10319000)
        libthr.so.3 => /lib/libthr.so.3 (0x10361000)
        libc.so.7 => /lib/libc.so.7 (0x10374000)
        libgcrypt.so.15 => /usr/local/lib/libgcrypt.so.15 (0x10473000)
        libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x104db000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x104df000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x104e8000)
        libvgl.so.5 => /usr/lib/libvgl.so.5 (0x105de000)
        libaa.so.1 => /usr/local/lib/libaa.so.1 (0x105e6000)
        libusbhid.so.3 => /usr/lib/libusbhid.so.3 (0x105fd000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x10601000)
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x106ed000)
        libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x106f0000)
        librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x106f5000)
>
>  Here is another experimental update that forces -lthr on 6.x, and
> also updates to qemu svn r5313:
>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch

I just built this update and it seems to have fixed the issue.  Host
CPU usage again tracks with guest CPU usage and all seems well.  I'll
continue to use this build to see if anything else crops up.

Please let me know if there is anything other information I can provide.

Thanks again,
Matt
>
> >Thank you for the continued work on this port!
>
>  You're welcome! :)
>        Juergen

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Anthony Liguori]

Matt wrote:
>>  Here is another experimental update that forces -lthr on 6.x, and
>> also updates to qemu svn r5313:
>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>     
>
> I just built this update and it seems to have fixed the issue.  Host
> CPU usage again tracks with guest CPU usage and all seems well.  I'll
> continue to use this build to see if anything else crops up.
>
> Please let me know if there is anything other information I can provide.
>   

If ya'll have patches to make QEMU work on FreeBSD, please submit them.  
I'm about to commit a patch that's what it took for me to get SVN 
working on FreeBSD.

The one thing that really tripped me up with the whole aio kld-module 
thing.  Perhaps we should detect the presence of the module at run time 
and disable aio?  I assume kldload can only be run as root?

Regards,

Anthony Liguori

> Thanks again,
> Matt
>   
>>> Thank you for the continued work on this port!
>>>       
>>  You're welcome! :)
>>        Juergen
>>     
>
>
>   

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Carlos A. M. dos Santos]

On Fri, Sep 26, 2008 at 12:04 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Matt wrote:
>>>
>>>  Here is another experimental update that forces -lthr on 6.x, and
>>> also updates to qemu svn r5313:
>>>       http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>>
>>
>> I just built this update and it seems to have fixed the issue.  Host
>> CPU usage again tracks with guest CPU usage and all seems well.  I'll
>> continue to use this build to see if anything else crops up.
>>
>> Please let me know if there is anything other information I can provide.
>>
>
> If ya'll have patches to make QEMU work on FreeBSD, please submit them.  I'm
> about to commit a patch that's what it took for me to get SVN working on
> FreeBSD.
>
> The one thing that really tripped me up with the whole aio kld-module thing.
>  Perhaps we should detect the presence of the module at run time and disable
> aio?  I assume kldload can only be run as root?

Yes, only root can load kernel modules. I think the best approach for
QEMU would be showing a message instructing the user kldload aio
and/or include a line in /boot/loader.conf countaining

     aio_load="YES"

-- 
cd /usr/ports/sysutils/life
make clean

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Juergen Lock]

On Fri, Sep 26, 2008 at 10:04:28AM -0500, Anthony Liguori wrote:
> Matt wrote:
>>>  Here is another experimental update that forces -lthr on 6.x, and
>>> also updates to qemu svn r5313:
>>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>>     
>> 
>> I just built this update and it seems to have fixed the issue.  Host
>> CPU usage again tracks with guest CPU usage and all seems well.  I'll
>> continue to use this build to see if anything else crops up.
>> 
>> Please let me know if there is anything other information I can provide.
>>   
> 
> If ya'll have patches to make QEMU work on FreeBSD, please submit them.  
> I'm about to commit a patch that's what it took for me to get SVN working 
> on FreeBSD.
> 
> The one thing that really tripped me up with the whole aio kld-module 
> thing.  Perhaps we should detect the presence of the module at run time and 
> disable aio?  I assume kldload can only be run as root?

Yes.  Atm the ports print a warning when aio is not loaded:

Index: qemu/vl.c
@@ -8409,6 +8409,11 @@
 
     tb_size = 0;
     
+#ifdef __FreeBSD__
+    if (modfind("aio") == -1)
+        fprintf(stderr, "warning: aio not (kld)loaded, may cause `Invalid system call' traps on disk IO\n");
+#endif
+
     optind = 1;
     for(;;) {
         if (optind >= argc)

 And here is another patch thats needed on amd64 hosts for tcg (which
I had posted before:)

Index: qemu/exec.c
@@ -405,6 +405,28 @@
             exit(1);
         }
     }
+#elif defined(__FreeBSD__)
+    {
+        int flags;
+        void *addr = NULL;
+        flags = MAP_PRIVATE | MAP_ANONYMOUS;
+#if defined(__x86_64__)
+        /* FreeBSD doesn't have MAP_32BIT, use MAP_FIXED and assume
+         * 0x40000000 is free */
+        flags |= MAP_FIXED;
+        addr = (void *)0x40000000;
+        /* Cannot map more than that */
+        if (code_gen_buffer_size > (800 * 1024 * 1024))
+            code_gen_buffer_size = (800 * 1024 * 1024);
+#endif
+        code_gen_buffer = mmap(addr, code_gen_buffer_size,
+                               PROT_WRITE | PROT_READ | PROT_EXEC, 
+                               flags, -1, 0);
+        if (code_gen_buffer == MAP_FAILED) {
+            fprintf(stderr, "Could not allocate dynamic translator buffer\n");
+            exit(1);
+        }
+    }
 #else
     code_gen_buffer = qemu_malloc(code_gen_buffer_size);
     if (!code_gen_buffer) {

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

 I'll see if I can prepare another update over the weekend and then go
thru more of the patches that have accumulated in the port...

 Thanx,
	Juergen

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Anthony Liguori]

Juergen Lock wrote:
> On Fri, Sep 26, 2008 at 10:04:28AM -0500, Anthony Liguori wrote:
>   
>> Matt wrote:
>>     
>>>>  Here is another experimental update that forces -lthr on 6.x, and
>>>> also updates to qemu svn r5313:
>>>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch
>>>>     
>>>>         
>>> I just built this update and it seems to have fixed the issue.  Host
>>> CPU usage again tracks with guest CPU usage and all seems well.  I'll
>>> continue to use this build to see if anything else crops up.
>>>
>>> Please let me know if there is anything other information I can provide.
>>>   
>>>       
>> If ya'll have patches to make QEMU work on FreeBSD, please submit them.  
>> I'm about to commit a patch that's what it took for me to get SVN working 
>> on FreeBSD.
>>
>> The one thing that really tripped me up with the whole aio kld-module 
>> thing.  Perhaps we should detect the presence of the module at run time and 
>> disable aio?  I assume kldload can only be run as root?
>>     
>
> Yes.  Atm the ports print a warning when aio is not loaded:
>   

Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
modfind("aio") is not available (printing a warning along with that 
would be fine).  A non-privileged user cannot load the aio module so 
it's not very useful to tell them to load it.

>  And here is another patch thats needed on amd64 hosts for tcg (which
> I had posted before:)
>
> Index: qemu/exec.c
> @@ -405,6 +405,28 @@
>              exit(1);
>          }
>      }
> +#elif defined(__FreeBSD__)
> +    {
> +        int flags;
> +        void *addr = NULL;
> +        flags = MAP_PRIVATE | MAP_ANONYMOUS;
> +#if defined(__x86_64__)
> +        /* FreeBSD doesn't have MAP_32BIT, use MAP_FIXED and assume
> +         * 0x40000000 is free */
> +        flags |= MAP_FIXED;
> +        addr = (void *)0x40000000;
> +        /* Cannot map more than that */
> +        if (code_gen_buffer_size > (800 * 1024 * 1024))
> +            code_gen_buffer_size = (800 * 1024 * 1024);
> +#endif
> +        code_gen_buffer = mmap(addr, code_gen_buffer_size,
> +                               PROT_WRITE | PROT_READ | PROT_EXEC, 
> +                               flags, -1, 0);
> +        if (code_gen_buffer == MAP_FAILED) {
> +            fprintf(stderr, "Could not allocate dynamic translator buffer\n");
> +            exit(1);
> +        }
> +    }
>  #else
>      code_gen_buffer = qemu_malloc(code_gen_buffer_size);
>      if (!code_gen_buffer) {
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>   

Applied.  Thanks.

>  I'll see if I can prepare another update over the weekend and then go
> thru more of the patches that have accumulated in the port...
>   

That would be great!

Regards,

Anthony Liguori

>  Thanx,
> 	Juergen
>   

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Juergen Lock]

In article <48DE5256.5000101@codemonkey.ws> you write:
>[...]

>>> The one thing that really tripped me up with the whole aio kld-module 
>>> thing.  Perhaps we should detect the presence of the module at run time and 
>>> disable aio?  I assume kldload can only be run as root?
>>>     
>>
>> Yes.  Atm the ports print a warning when aio is not loaded:
>>   
>
>Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
>modfind("aio") is not available (printing a warning along with that 
>would be fine).  A non-privileged user cannot load the aio module so 
>it's not very useful to tell them to load it.

OK so how about the following?  (only tested with a raw image, but if
the way its disabled for OpenBSD works for all of them this should as well.)

 Oh and am I right qemu-img doesn't use aio?  If it actually does we may
want to add the same check there instead of just disabling it.  (I kept it
enabled for qemu-nbd since thats not built on FreeBSD anyway.)

Index: qemu/block.h
@@ -50,10 +50,9 @@
 #define BDRV_O_DIRECT      0x0020
 #define BDRV_O_AUTOGROW    0x0040 /* Allow backing file to extend when writing past end of file */
 
-void bdrv_info(void);
+void bdrv_init(int emulate_aio);
 void bdrv_info_stats(void);
 
-void bdrv_init(void);
 BlockDriver *bdrv_find_format(const char *format_name);
 int bdrv_create(BlockDriver *drv,
                 const char *filename, int64_t size_in_sectors,
Index: qemu/block.c
@@ -177,9 +177,9 @@
 }
 
 
-static void bdrv_register(BlockDriver *bdrv)
+static void bdrv_register(BlockDriver *bdrv, int emulate_aio)
 {
-    if (!bdrv->bdrv_aio_read) {
+    if (!bdrv->bdrv_aio_read || emulate_aio) {
         /* add AIO emulation layer */
         bdrv->bdrv_aio_read = bdrv_aio_read_em;
         bdrv->bdrv_aio_write = bdrv_aio_write_em;
@@ -1374,23 +1374,23 @@
     return async_ret;
 }
 
-void bdrv_init(void)
+void bdrv_init(int emulate_aio)
 {
-    bdrv_register(&bdrv_raw);
-    bdrv_register(&bdrv_host_device);
+    bdrv_register(&bdrv_raw, emulate_aio);
+    bdrv_register(&bdrv_host_device, 0);
 #ifndef _WIN32
-    bdrv_register(&bdrv_cow);
+    bdrv_register(&bdrv_cow, 0);
 #endif
-    bdrv_register(&bdrv_qcow);
-    bdrv_register(&bdrv_vmdk);
-    bdrv_register(&bdrv_cloop);
-    bdrv_register(&bdrv_dmg);
-    bdrv_register(&bdrv_bochs);
-    bdrv_register(&bdrv_vpc);
-    bdrv_register(&bdrv_vvfat);
-    bdrv_register(&bdrv_qcow2);
-    bdrv_register(&bdrv_parallels);
-    bdrv_register(&bdrv_nbd);
+    bdrv_register(&bdrv_qcow, 0);
+    bdrv_register(&bdrv_vmdk, 0);
+    bdrv_register(&bdrv_cloop, 0);
+    bdrv_register(&bdrv_dmg, 0);
+    bdrv_register(&bdrv_bochs, 0);
+    bdrv_register(&bdrv_vpc, 0);
+    bdrv_register(&bdrv_vvfat, 0);
+    bdrv_register(&bdrv_qcow2, 0);
+    bdrv_register(&bdrv_parallels, 0);
+    bdrv_register(&bdrv_nbd, 0);
 }
 
 void *qemu_aio_get(BlockDriverState *bs, BlockDriverCompletionFunc *cb,
Index: qemu/vl.c
@@ -8609,6 +8609,7 @@
     int tb_size;
     const char *pid_file = NULL;
     VLANState *vlan;
+    int emulate_aio = 0;
 
     LIST_INIT (&vm_change_state_head);
 #ifndef _WIN32
@@ -8681,6 +8682,13 @@
 
     tb_size = 0;
     
+#ifdef __FreeBSD__
+    if (modfind("aio") == -1) {
+        emulate_aio = 1;
+        fprintf(stderr, "warning: aio not (kld)loaded, disabling (may slow down on disk IO\n");
+    }
+#endif
+
     optind = 1;
     for(;;) {
         if (optind >= argc)
@@ -9415,7 +9423,7 @@
     /* init the dynamic translator */
     cpu_exec_init_all(tb_size * 1024 * 1024);
 
-    bdrv_init();
+    bdrv_init(emulate_aio);
 
     /* we always create the cdrom drive, even if no disk is there */
 
Index: qemu/qemu-img.c
@@ -733,7 +733,7 @@
 {
     const char *cmd;
 
-    bdrv_init();
+    bdrv_init(1);
     if (argc < 2)
         help();
     cmd = argv[1];
Index: qemu/qemu-nbd.c
@@ -326,7 +326,7 @@
 	return 0;
     }
 
-    bdrv_init();
+    bdrv_init(0);
 
     bs = bdrv_new("hda");
     if (bs == NULL)

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Anthony Liguori]

Juergen Lock wrote:
> In article <48DE5256.5000101@codemonkey.ws> you write:
>   
>> [...]
>>     
>
>   
>>>> The one thing that really tripped me up with the whole aio kld-module 
>>>> thing.  Perhaps we should detect the presence of the module at run time and 
>>>> disable aio?  I assume kldload can only be run as root?
>>>>     
>>>>         
>>> Yes.  Atm the ports print a warning when aio is not loaded:
>>>   
>>>       
>> Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
>> modfind("aio") is not available (printing a warning along with that 
>> would be fine).  A non-privileged user cannot load the aio module so 
>> it's not very useful to tell them to load it.
>>     
>
> OK so how about the following?  (only tested with a raw image, but if
> the way its disabled for OpenBSD works for all of them this should as well.)
>
>  Oh and am I right qemu-img doesn't use aio?  If it actually does we may
> want to add the same check there instead of just disabling it.  (I kept it
> enabled for qemu-nbd since thats not built on FreeBSD anyway.)
>   

Disabling aio for everyone is not the right thing if posix-aio is broken.

What would be better is in block-raw-posix.c, to have a one type check 
of modfind() (if we're FreeBSD), and if it fails, set a flag that forces 
the aio routines to call bdrv_aio_{read,write}_em.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313)

[Juergen Lock]

On Tue, Sep 30, 2008 at 09:51:33AM -0500, Anthony Liguori wrote:
> Juergen Lock wrote:
>> In article <48DE5256.5000101@codemonkey.ws> you write:
>>   
>>> [...]
>>>     
>> 
>>   
>>>>> The one thing that really tripped me up with the whole aio kld-module 
>>>>> thing.  Perhaps we should detect the presence of the module at run time 
>>>>> and disable aio?  I assume kldload can only be run as root?
>>>>>             
>>>> Yes.  Atm the ports print a warning when aio is not loaded:
>>>>         
>>> Yeah, I don't think this is enough.  I'd rather see AIO be disabled when 
>>> modfind("aio") is not available (printing a warning along with that would 
>>> be fine).  A non-privileged user cannot load the aio module so it's not 
>>> very useful to tell them to load it.
>>>     
>> 
>> OK so how about the following?  (only tested with a raw image, but if
>> the way its disabled for OpenBSD works for all of them this should as well.)
>> 
>>  Oh and am I right qemu-img doesn't use aio?  If it actually does we may
>> want to add the same check there instead of just disabling it.  (I kept it
>> enabled for qemu-nbd since thats not built on FreeBSD anyway.)
>>   
> 
> Disabling aio for everyone is not the right thing if posix-aio is broken.
> 
Well, I went after what is done for the OpenBSD case (CONFIG_AIO not set),
i.e. tell bdrv_register() to set bdrv_aio_read & frieds to bdrv_aio_read_em
etc for bdrv_raw if aio is not loaded.  I found one bug tho, the same
should be done for bdrv_host_device, i.e. in block.c
	bdrv_register(&bdrv_host_device, 0);
should be
	bdrv_register(&bdrv_host_device, emulate_aio);
too.  The 0 for the others there mean don't emulate i.e. keep aio enabled...

 Or are you talking about qemu-img?  If that would in fact benefit from
using aio like this too we could just add the same test as in vl.c.
(Or we could move the test to bdrv_init(), I just didn't want to print
the warning from in there.)

> What would be better is in block-raw-posix.c, to have a one type check of 
> modfind() (if we're FreeBSD), and if it fails, set a flag that forces the 
> aio routines to call bdrv_aio_{read,write}_em.
> 
 You mean runtime checks every time a raw aio fn is called (even if just
a flag?)  That's what I was trying to avoid... :)

 Regards,
	Juergen

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5331)

[Juergen Lock]

On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>[...]
>  I'll see if I can prepare another update over the weekend and then go
> thru more of the patches that have accumulated in the port...

OK, here we go :)  First the update: (at r5331 now)
	http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch

1. FreeBSD also has clock_gettime:

Index: qemu/vl.c
@@ -541,7 +541,7 @@
 static void init_get_clock(void)
 {
     use_rt_clock = 0;
-#if defined(__linux__)
+#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
     {
         struct timespec ts;
         if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
@@ -553,7 +553,7 @@
 
 static int64_t get_clock(void)
 {
-#if defined(__linux__)
+#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
     if (use_rt_clock) {
         struct timespec ts;
         clock_gettime(CLOCK_MONOTONIC, &ts);

2. open() can also return EPERM for O_RDWR on a readonly device (I think
the case where this happened was a cdrom:)

Index: qemu/block.c
@@ -381,7 +381,7 @@
     else
         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
     ret = drv->bdrv_open(bs, filename, open_flags);
-    if (ret == -EACCES && !(flags & BDRV_O_FILE)) {
+    if ((ret == -EACCES || ret == -EPERM) && !(flags & BDRV_O_FILE)) {
         ret = drv->bdrv_open(bs, filename, BDRV_O_RDONLY);
         bs->read_only = 1;
     }

3. the following bugfix is needed at least for FreeBSD/amd64 guests:
(original patch from
	http://www.nabble.com/-PATCH--i386-hard-interrupt-generation-bug-fix-p14921171.html
)

Index: qemu/cpu-exec.c
@@ -394,16 +394,18 @@
                                      (env->eflags & IF_MASK && 
                                       !(env->hflags & HF_INHIBIT_IRQ_MASK))))) {
                             int intno;
-                            svm_check_intercept(SVM_EXIT_INTR);
                             env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
                             intno = cpu_get_pic_interrupt(env);
-                            if (loglevel & CPU_LOG_TB_IN_ASM) {
-                                fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
+                            if (intno>=0) {
+                                svm_check_intercept(SVM_EXIT_INTR);
+                                if (loglevel & CPU_LOG_TB_IN_ASM) {
+                                    fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
+                                }
+                                do_interrupt(intno, 0, 0, 0, 1);
+                                /* ensure that no TB jump will be modified as
+                                   the program flow was changed */
+                                next_tb = 0;
                             }
-                            do_interrupt(intno, 0, 0, 0, 1);
-                            /* ensure that no TB jump will be modified as
-                               the program flow was changed */
-                            next_tb = 0;
 #if !defined(CONFIG_USER_ONLY)
                         } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
                                    (env->eflags & IF_MASK) && 

4. this is also needed for (some?) amd64 guests on i386 hosts:

Index: qemu/exec-all.h
@@ -30,7 +30,7 @@
 struct TranslationBlock;
 
 /* XXX: make safe guess about sizes */
-#define MAX_OP_PER_INSTR 64
+#define MAX_OP_PER_INSTR 128 /* 64 */
 /* A Call op needs up to 6 + 2N parameters (N = number of arguments).  */
 #define MAX_OPC_PARAM 10
 #define OPC_BUF_SIZE 512

5. no need (?) for a dummy file on FreeBSD too: (like on OpenBSD)

Index: qemu/osdep.c
@@ -75,8 +75,10 @@
 #include <sys/types.h>
 #include <sys/mount.h>
 #else
+#ifndef __FreeBSD__
 #include <sys/vfs.h>
 #endif
+#endif
 
 #include <sys/mman.h>
 #include <fcntl.h>
@@ -87,7 +87,7 @@
     static int phys_ram_size = 0;
     void *ptr;
 
-#ifdef __OpenBSD__ /* no need (?) for a dummy file on OpenBSD */
+#if defined(__OpenBSD__) || defined(__FreeBSD__) /* no need (?) for a dummy file on OpenBSD/FreeBSD */
     int map_anon = MAP_ANON;
 #else
     int map_anon = 0;
@@ -154,7 +154,7 @@
     }
     size = (size + 4095) & ~4095;
     ftruncate(phys_ram_fd, phys_ram_size + size);
-#endif /* !__OpenBSD__ */
+#endif /* !(__OpenBSD__ || __FreeBSD__) */
     ptr = mmap(NULL,
                size,
                PROT_WRITE | PROT_READ, map_anon | MAP_SHARED,

6. correct lib search path on FreeBSD/amd64 hosts (tho this needs to be
conditionally applied if its to go into qemu svn:)

Index: qemu/x86_64.ld
@@ -2,7 +2,7 @@
 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
 OUTPUT_ARCH(i386:x86-64)
 ENTRY(_start)
-SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib64");
+SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */

 I think thats it for now...  more maybe later.
	Juergen

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5331)

[Carlos A. M. dos Santos]

On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>>[...]
>>  I'll see if I can prepare another update over the weekend and then go
>> thru more of the patches that have accumulated in the port...
>
> OK, here we go :)  First the update: (at r5331 now)
>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>
> 1. FreeBSD also has clock_gettime:
>
> Index: qemu/vl.c
> @@ -541,7 +541,7 @@
>  static void init_get_clock(void)
>  {
>     use_rt_clock = 0;
> -#if defined(__linux__)
> +#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
>     {
>         struct timespec ts;
>         if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
> @@ -553,7 +553,7 @@
>
>  static int64_t get_clock(void)
>  {
> -#if defined(__linux__)
> +#if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
>     if (use_rt_clock) {
>         struct timespec ts;
>         clock_gettime(CLOCK_MONOTONIC, &ts);
>
> 2. open() can also return EPERM for O_RDWR on a readonly device (I think
> the case where this happened was a cdrom:)
>
> Index: qemu/block.c
> @@ -381,7 +381,7 @@
>     else
>         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
>     ret = drv->bdrv_open(bs, filename, open_flags);
> -    if (ret == -EACCES && !(flags & BDRV_O_FILE)) {
> +    if ((ret == -EACCES || ret == -EPERM) && !(flags & BDRV_O_FILE)) {
>         ret = drv->bdrv_open(bs, filename, BDRV_O_RDONLY);
>         bs->read_only = 1;
>     }
>
> 3. the following bugfix is needed at least for FreeBSD/amd64 guests:
> (original patch from
>        http://www.nabble.com/-PATCH--i386-hard-interrupt-generation-bug-fix-p14921171.html
> )
>
> Index: qemu/cpu-exec.c
> @@ -394,16 +394,18 @@
>                                      (env->eflags & IF_MASK &&
>                                       !(env->hflags & HF_INHIBIT_IRQ_MASK))))) {
>                             int intno;
> -                            svm_check_intercept(SVM_EXIT_INTR);
>                             env->interrupt_request &= ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
>                             intno = cpu_get_pic_interrupt(env);
> -                            if (loglevel & CPU_LOG_TB_IN_ASM) {
> -                                fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
> +                            if (intno>=0) {
> +                                svm_check_intercept(SVM_EXIT_INTR);
> +                                if (loglevel & CPU_LOG_TB_IN_ASM) {
> +                                    fprintf(logfile, "Servicing hardware INT=0x%02x\n", intno);
> +                                }
> +                                do_interrupt(intno, 0, 0, 0, 1);
> +                                /* ensure that no TB jump will be modified as
> +                                   the program flow was changed */
> +                                next_tb = 0;
>                             }
> -                            do_interrupt(intno, 0, 0, 0, 1);
> -                            /* ensure that no TB jump will be modified as
> -                               the program flow was changed */
> -                            next_tb = 0;
>  #if !defined(CONFIG_USER_ONLY)
>                         } else if ((interrupt_request & CPU_INTERRUPT_VIRQ) &&
>                                    (env->eflags & IF_MASK) &&
>
> 4. this is also needed for (some?) amd64 guests on i386 hosts:
>
> Index: qemu/exec-all.h
> @@ -30,7 +30,7 @@
>  struct TranslationBlock;
>
>  /* XXX: make safe guess about sizes */
> -#define MAX_OP_PER_INSTR 64
> +#define MAX_OP_PER_INSTR 128 /* 64 */
>  /* A Call op needs up to 6 + 2N parameters (N = number of arguments).  */
>  #define MAX_OPC_PARAM 10
>  #define OPC_BUF_SIZE 512
>
> 5. no need (?) for a dummy file on FreeBSD too: (like on OpenBSD)
>
> Index: qemu/osdep.c
> @@ -75,8 +75,10 @@
>  #include <sys/types.h>
>  #include <sys/mount.h>
>  #else
> +#ifndef __FreeBSD__
>  #include <sys/vfs.h>
>  #endif
> +#endif
>
>  #include <sys/mman.h>
>  #include <fcntl.h>
> @@ -87,7 +87,7 @@
>     static int phys_ram_size = 0;
>     void *ptr;
>
> -#ifdef __OpenBSD__ /* no need (?) for a dummy file on OpenBSD */
> +#if defined(__OpenBSD__) || defined(__FreeBSD__) /* no need (?) for a dummy file on OpenBSD/FreeBSD */
>     int map_anon = MAP_ANON;
>  #else
>     int map_anon = 0;
> @@ -154,7 +154,7 @@
>     }
>     size = (size + 4095) & ~4095;
>     ftruncate(phys_ram_fd, phys_ram_size + size);
> -#endif /* !__OpenBSD__ */
> +#endif /* !(__OpenBSD__ || __FreeBSD__) */
>     ptr = mmap(NULL,
>                size,
>                PROT_WRITE | PROT_READ, map_anon | MAP_SHARED,
>
> 6. correct lib search path on FreeBSD/amd64 hosts (tho this needs to be
> conditionally applied if its to go into qemu svn:)
>
> Index: qemu/x86_64.ld
> @@ -2,7 +2,7 @@
>  OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
>  OUTPUT_ARCH(i386:x86-64)
>  ENTRY(_start)
> -SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib64");
> +SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");
>  SECTIONS
>  {
>   /* Read-only sections, merged into text segment: */
>
>  I think thats it for now...  more maybe later.
>        Juergen
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

I suggest applying the following patch (on top of yours). It includes
options to build additional sound emulators.

--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
+++ Makefile	2008-09-28 00:53:03.000000000 -0300
@@ -38,6 +38,10 @@
 		GNUTLS "gnutls dependency (vnc encryption)" On \
 		PCAP "pcap dependency (networking with bpf)" On \
 		CDROM_DMA "IDE CDROM DMA" On \
+		AC97 "Intel 82801AA AC97 sound card" Off \
+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
+		GUS "Gravis Ultrasound GF1 sound card" Off \
 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On

 .include <bsd.port.pre.mk>
@@ -76,6 +80,35 @@
 CONFIGURE_ARGS+=	--enable-pcap
 .endif

+.if defined(WITH_AC97)
+AUDIO_CARD_LIST=	ac97
+.endif
+
+.if defined(WITH_ADLIB)
+.if defined(AUDIO_CARD_LIST)
+AUDIO_CARD_LIST+=	,
+.endif
+AUDIO_CARD_LIST+=	adlib
+.endif
+
+.if defined(WITH_CS4231A)
+.if defined(AUDIO_CARD_LIST)
+AUDIO_CARD_LIST+=	,
+.endif
+AUDIO_CARD_LIST+=	cs4231a
+.endif
+
+.if defined(WITH_GUS)
+.if defined(AUDIO_CARD_LIST)
+AUDIO_CARD_LIST+=	,
+.endif
+AUDIO_CARD_LIST+=	gus
+.endif
+
+.if defined(AUDIO_CARD_LIST)
+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
+.endif
+
 .if defined(WITH_SAMBA)
 RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
 .endif

Signed-off-by: Carlos Santos <unixmania@gmail.com>

-- 
cd /usr/ports/sysutils/life
make clean

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5331)

[Juergen Lock]

In article <e71790db0809272104p1b3f383epb753fff72bb6f101@mail.gmail.com> you write:
>On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>>>[...]
>>>  I'll see if I can prepare another update over the weekend and then go
>>> thru more of the patches that have accumulated in the port...
>>
>> OK, here we go :)  First the update: (at r5331 now)
>>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>[...]
>
>I suggest applying the following patch (on top of yours). It includes
>options to build additional sound emulators.
>
>--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
>+++ Makefile	2008-09-28 00:53:03.000000000 -0300
>@@ -38,6 +38,10 @@
> 		GNUTLS "gnutls dependency (vnc encryption)" On \
> 		PCAP "pcap dependency (networking with bpf)" On \
> 		CDROM_DMA "IDE CDROM DMA" On \
>+		AC97 "Intel 82801AA AC97 sound card" Off \
>+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
>+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
>+		GUS "Gravis Ultrasound GF1 sound card" Off \
> 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On
>
> .include <bsd.port.pre.mk>
>@@ -76,6 +80,35 @@
> CONFIGURE_ARGS+=	--enable-pcap
> .endif
>
>+.if defined(WITH_AC97)
>+AUDIO_CARD_LIST=	ac97
>+.endif
>+
>+.if defined(WITH_ADLIB)
>+.if defined(AUDIO_CARD_LIST)
>+AUDIO_CARD_LIST+=	,
>+.endif
>+AUDIO_CARD_LIST+=	adlib
>+.endif
>+
>+.if defined(WITH_CS4231A)
>+.if defined(AUDIO_CARD_LIST)
>+AUDIO_CARD_LIST+=	,
>+.endif
>+AUDIO_CARD_LIST+=	cs4231a
>+.endif
>+
>+.if defined(WITH_GUS)
>+.if defined(AUDIO_CARD_LIST)
>+AUDIO_CARD_LIST+=	,
>+.endif
>+AUDIO_CARD_LIST+=	gus
>+.endif
>+
>+.if defined(AUDIO_CARD_LIST)
>+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
>+.endif
>+
> .if defined(WITH_SAMBA)
> RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
> .endif
>
>Signed-off-by: Carlos Santos <unixmania@gmail.com>

Hmm.  I might just add one knob to compile in all of these instead,
they are still to be enabled individually at runtime, right?

 Thanx,
	Juergen

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5457)

[Juergen Lock]

On Wed, Oct 01, 2008 at 12:33:39AM +0200, Juergen Lock wrote:
> In article <e71790db0809272104p1b3f383epb753fff72bb6f101@mail.gmail.com> you write:
> >On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> >> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
> >>>[...]
> >>>  I'll see if I can prepare another update over the weekend and then go
> >>> thru more of the patches that have accumulated in the port...
> >>
> >> OK, here we go :)  First the update: (at r5331 now)
> >>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
> >[...]
> >
> >I suggest applying the following patch (on top of yours). It includes
> >options to build additional sound emulators.
> >
> >--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
> >+++ Makefile	2008-09-28 00:53:03.000000000 -0300
> >@@ -38,6 +38,10 @@
> > 		GNUTLS "gnutls dependency (vnc encryption)" On \
> > 		PCAP "pcap dependency (networking with bpf)" On \
> > 		CDROM_DMA "IDE CDROM DMA" On \
> >+		AC97 "Intel 82801AA AC97 sound card" Off \
> >+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
> >+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
> >+		GUS "Gravis Ultrasound GF1 sound card" Off \
> > 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On
> >
> > .include <bsd.port.pre.mk>
> >@@ -76,6 +80,35 @@
> > CONFIGURE_ARGS+=	--enable-pcap
> > .endif
> >
> >+.if defined(WITH_AC97)
> >+AUDIO_CARD_LIST=	ac97
> >+.endif
> >+
> >+.if defined(WITH_ADLIB)
> >+.if defined(AUDIO_CARD_LIST)
> >+AUDIO_CARD_LIST+=	,
> >+.endif
> >+AUDIO_CARD_LIST+=	adlib
> >+.endif
> >+
> >+.if defined(WITH_CS4231A)
> >+.if defined(AUDIO_CARD_LIST)
> >+AUDIO_CARD_LIST+=	,
> >+.endif
> >+AUDIO_CARD_LIST+=	cs4231a
> >+.endif
> >+
> >+.if defined(WITH_GUS)
> >+.if defined(AUDIO_CARD_LIST)
> >+AUDIO_CARD_LIST+=	,
> >+.endif
> >+AUDIO_CARD_LIST+=	gus
> >+.endif
> >+
> >+.if defined(AUDIO_CARD_LIST)
> >+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
> >+.endif
> >+
> > .if defined(WITH_SAMBA)
> > RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
> > .endif
> >
> >Signed-off-by: Carlos Santos <unixmania@gmail.com>
> 
> Hmm.  I might just add one knob to compile in all of these instead,
> they are still to be enabled individually at runtime, right?

Ok, new update at:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20081011.patch
I have added an ADD_AUDIO knob to enable all of the above, and I have
also added the aio emulation patch that makes qemu still work when aio
is not loaded (although usually slower.)

 I have noticed tho that -soundhw ac97 together with -usb -drive if=scsi,...
and -net nic,model=rtl8139 causes scsi resets and timeouts at least for my
sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso livecd guest, can
anyone reproduce this?  A FreeBSD 7.1-BETA-i386-livefs.iso guest with the
same parameters also hangs at boot with scsi problems...

 Oh and the other problems I mentioned also still seem to exist.

 Thanx,
	Juergen

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5499)

[Juergen Lock]

On Sat, Oct 11, 2008 at 11:41:48PM +0200, Juergen Lock wrote:
> On Wed, Oct 01, 2008 at 12:33:39AM +0200, Juergen Lock wrote:
> > In article <e71790db0809272104p1b3f383epb753fff72bb6f101@mail.gmail.com> you write:
> > >On Sat, Sep 27, 2008 at 5:47 PM, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > >> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
> > >>>[...]
> > >>>  I'll see if I can prepare another update over the weekend and then go
> > >>> thru more of the patches that have accumulated in the port...
> > >>
> > >> OK, here we go :)  First the update: (at r5331 now)
> > >>        http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
> > >[...]
> > >
> > >I suggest applying the following patch (on top of yours). It includes
> > >options to build additional sound emulators.
> > >
> > >--- Makefile.orig	2008-09-28 00:11:29.000000000 -0300
> > >+++ Makefile	2008-09-28 00:53:03.000000000 -0300
> > >@@ -38,6 +38,10 @@
> > > 		GNUTLS "gnutls dependency (vnc encryption)" On \
> > > 		PCAP "pcap dependency (networking with bpf)" On \
> > > 		CDROM_DMA "IDE CDROM DMA" On \
> > >+		AC97 "Intel 82801AA AC97 sound card" Off \
> > >+		ADLIB "Adlib card with Yamaha YM3812 (OPL2) chip" Off \
> > >+		CS4231A "CS4231A sound card (Windows Sound System)" Off \
> > >+		GUS "Gravis Ultrasound GF1 sound card" Off \
> > > 		ALL_TARGETS "Also build dyngen targets (requires gcc34)" On
> > >
> > > .include <bsd.port.pre.mk>
> > >@@ -76,6 +80,35 @@
> > > CONFIGURE_ARGS+=	--enable-pcap
> > > .endif
> > >
> > >+.if defined(WITH_AC97)
> > >+AUDIO_CARD_LIST=	ac97
> > >+.endif
> > >+
> > >+.if defined(WITH_ADLIB)
> > >+.if defined(AUDIO_CARD_LIST)
> > >+AUDIO_CARD_LIST+=	,
> > >+.endif
> > >+AUDIO_CARD_LIST+=	adlib
> > >+.endif
> > >+
> > >+.if defined(WITH_CS4231A)
> > >+.if defined(AUDIO_CARD_LIST)
> > >+AUDIO_CARD_LIST+=	,
> > >+.endif
> > >+AUDIO_CARD_LIST+=	cs4231a
> > >+.endif
> > >+
> > >+.if defined(WITH_GUS)
> > >+.if defined(AUDIO_CARD_LIST)
> > >+AUDIO_CARD_LIST+=	,
> > >+.endif
> > >+AUDIO_CARD_LIST+=	gus
> > >+.endif
> > >+
> > >+.if defined(AUDIO_CARD_LIST)
> > >+CONFIGURE_ARGS+=	--audio-card-list="${AUDIO_CARD_LIST}"
> > >+.endif
> > >+
> > > .if defined(WITH_SAMBA)
> > > RUN_DEPENDS+=	${LOCALBASE}/sbin/smbd:${PORTSDIR}/net/samba3
> > > .endif
> > >
> > >Signed-off-by: Carlos Santos <unixmania@gmail.com>
> > 
> > Hmm.  I might just add one knob to compile in all of these instead,
> > they are still to be enabled individually at runtime, right?
> 
> Ok, new update at:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20081011.patch
> I have added an ADD_AUDIO knob to enable all of the above, and I have
> also added the aio emulation patch that makes qemu still work when aio
> is not loaded (although usually slower.)
> 
New update at:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20081018.patch
I have removed the cpu-exec.c patch as it seems(!) no longer needed,
and I have added a fix for -m >= 1024 on recent FreeBSD/amd64 hosts,
I'll post about that seperately.

>  I have noticed tho that -soundhw ac97 together with -usb -drive if=scsi,...
> and -net nic,model=rtl8139 causes scsi resets and timeouts at least for my
> sidux-2008-03-ourea-pre1-kde-lite-i386-200809142136.iso livecd guest, can
> anyone reproduce this?  A FreeBSD 7.1-BETA-i386-livefs.iso guest with the
> same parameters also hangs at boot with scsi problems...
> 
 I was unable to reproduce this when trying it like that again, it appears
I had passed both -soundhw es1370 _and_ -soundhw ac97 when I saw this. :(
Sorry for any confusion this might have caused...

>  Oh and the other problems I mentioned also still seem to exist.

 Same.

 I'm beginning to suspect tho that the screen update thing I mentioned
is an xorg intel driver problem not a qemu one... (that box has Intel
965GM graphics, and the non-updated parts on the screen seem to depend on
the vertial height of the other window that I last moused over when it
happens, which would be too weird a bug for qemu to cause it, right? :)

 Regards,
	Juergen

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5331)

[Anthony Liguori]

Juergen Lock wrote:
> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>   
>> [...]
>>  I'll see if I can prepare another update over the weekend and then go
>> thru more of the patches that have accumulated in the port...
>>     
>
> OK, here we go :)  First the update: (at r5331 now)
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>   

Can you send this out as a series of patches?  It's much easier to 
comment and apply them that way.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5331)

[Juergen Lock]

In article <48E23D47.4030602@codemonkey.ws> you write:
>Juergen Lock wrote:
>> On Sat, Sep 27, 2008 at 12:04:45AM +0200, I wrote:
>>   
>>> [...]
>>>  I'll see if I can prepare another update over the weekend and then go
>>> thru more of the patches that have accumulated in the port...
>>>     
>>
>> OK, here we go :)  First the update: (at r5331 now)
>> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080927.patch
>>   
>
>Can you send this out as a series of patches?  It's much easier to 
>comment and apply them that way.

OK, but not today. :)

 Regards,
	Juergen

[Qemu-devel] [PATCH] preprocessor issue in qemu/patch-block-raw-posix.c (was: qemu svn r5281 on FreeBSD - slow usb, vmwarevga, screen updates... (now updated to r5313))

[Juergen Lock]

On Thu, Sep 25, 2008 at 12:10:39AM +0200, Juergen Lock wrote:
> In article <cd6b4a5b0809230639x27e94477k315796c2cfb650f2@mail.gmail.com> you write:
> >On Sun, Sep 21, 2008 at 3:40 PM, Juergen Lock <nox@jelal.kn-bremen.de> 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:
> >
> >Hi.  I've built an updated port with your patch and it compiles fine
> >and runs my WinXP guests well.  But, the qemu process consumes 100% of
> >one CPU core on the host the whole time it is running, regardless of
> >what the guest is doing.  The host is a 7-STABLE box from 8/19.  The
> >guests run with bridged networking and full kernel kqemu accel
> >enabled.
> >
> Hmm.  And you didn't see this with the version in ports?  Have you
> checked if this is related to kqemu? (try without -kernel-kqemu and
> also with -no-kqemu.)  Also, which threading libs and scheduler are you
> using?  There seems to be an issue with kse, tho I doubt you are using
> that on 7-stable...
> 
>  Here is another experimental update that forces -lthr on 6.x, and
> also updates to qemu svn r5313:
> 	http://people.freebsd.org/~nox/qemu/qemu-devel-20080924.patch

I forgot to note that this also needed the following patch:

Index: qemu/block-raw-posix.c
@@ -545,7 +545,8 @@
 
     qemu_aio_set_fd_handler(s->fd, posix_aio_read, NULL, posix_aio_flush, s);
 
-#if defined(__linux__) && defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 4)
+#if defined(__linux__) && defined(__GLIBC_PREREQ)
+#if !__GLIBC_PREREQ(2, 4)
     {
         /* XXX: aio thread exit seems to hang on RedHat 9 and this init
            seems to fix the problem. */
@@ -557,6 +558,7 @@
         aio_init(&ai);
     }
 #endif
+#endif
     posix_aio_state = s;
 
     return 0;

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

Re: [Qemu-devel] [PATCH] preprocessor issue in qemu/patch-block-raw-posix.c

[Anthony Liguori]

Juergen Lock wrote:
> I forgot to note that this also needed the following patch:
>   

Why?  This #ifdef is working around a very specific bug.

Regards,

Anthony Liguori

> Index: qemu/block-raw-posix.c
> @@ -545,7 +545,8 @@
>  
>      qemu_aio_set_fd_handler(s->fd, posix_aio_read, NULL, posix_aio_flush, s);
>  
> -#if defined(__linux__) && defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 4)
> +#if defined(__linux__) && defined(__GLIBC_PREREQ)
> +#if !__GLIBC_PREREQ(2, 4)
>      {
>          /* XXX: aio thread exit seems to hang on RedHat 9 and this init
>             seems to fix the problem. */
> @@ -557,6 +558,7 @@
>          aio_init(&ai);
>      }
>  #endif
> +#endif
>      posix_aio_state = s;
>  
>      return 0;
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>
>
>   

Re: [Qemu-devel] [PATCH] preprocessor issue in qemu/patch-block-raw-posix.c

[Juergen Lock]

On Thu, Sep 25, 2008 at 03:39:58PM -0500, Anthony Liguori wrote:
> Juergen Lock wrote:
>> I forgot to note that this also needed the following patch:
>>   
> 
> Why?  This #ifdef is working around a very specific bug.
> 
Well, looks like the preprocessor tries to parse the entire expression
including the undefined `!__GLIBC_PREREQ(2, 4)' before evaluating it:

block-raw-posix.c:548:69: missing binary operator before token "("

so I just put it on an extra line.

> Regards,
> 
> Anthony Liguori
> 
>> Index: qemu/block-raw-posix.c
>> @@ -545,7 +545,8 @@
>>       qemu_aio_set_fd_handler(s->fd, posix_aio_read, NULL, 
>> posix_aio_flush, s);
>>  -#if defined(__linux__) && defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 
>> 4)
>> +#if defined(__linux__) && defined(__GLIBC_PREREQ)
>> +#if !__GLIBC_PREREQ(2, 4)
>>      {
>>          /* XXX: aio thread exit seems to hang on RedHat 9 and this init
>>             seems to fix the problem. */
>> @@ -557,6 +558,7 @@
>>          aio_init(&ai);
>>      }
>>  #endif
>> +#endif
>>      posix_aio_state = s;
>>       return 0;
>> 
>> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
>> 
>> 
>>   
> 

Re: [Qemu-devel] [PATCH] preprocessor issue in qemu/patch-block-raw-posix.c

[Anthony Liguori]

Juergen Lock wrote:
> On Thu, Sep 25, 2008 at 03:39:58PM -0500, Anthony Liguori wrote:
>   
>> Juergen Lock wrote:
>>     
>>> I forgot to note that this also needed the following patch:
>>>   
>>>       
>> Why?  This #ifdef is working around a very specific bug.
>>
>>     
> Well, looks like the preprocessor tries to parse the entire expression
> including the undefined `!__GLIBC_PREREQ(2, 4)' before evaluating it:
>
> block-raw-posix.c:548:69: missing binary operator before token "("
>
> so I just put it on an extra line.
>   

It's fixed in SVN now.

Regards,

Anthony Liguori