[Qemu-devel] [regression] configure: add opengl detection

[Qemu-devel] [regression] configure: add opengl detection

[Benjamin Poirier]

Hello,

commit 20ff075bb3340c5278a0da38ad1f4d602565aa06
Author: Michael Walle <michael@walle.cc>
Date:   Mon Mar 7 23:32:39 2011 +0100

    configure: add opengl detection

    This patch introduce a new config option CONFIG_OPENGL.

    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

introduces a segfault for me with following backtrace:

Starting program:
/home/ben/local/src/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1G -net
none -drive file=/home/ben/diskImages/debian_squeeze_amd64.qcow2,snapshot=on
-nographic
[Thread debugging using libthread_db enabled]
[New Thread 0x7fff9ee07700 (LWP 19445)]

Program received signal SIGUSR2, User defined signal 2.
0x00007ffff5624ff3 in select () from /lib/libc.so.6
(gdb) info stack
#0  0x00007ffff5624ff3 in select () from /lib/libc.so.6
#1  0x000000000042edfa in qemu_aio_wait () at aio.c:193
#2  0x000000000042dd65 in bdrv_read_em (bs=0x11277c0, sector_num=0,
buf=0x7fffffffd9d0 "\353c\220\020\216м", nb_sectors=1)
    at block.c:2660
#3  0x000000000042b790 in guess_disk_lchs (bs=0x11277c0,
pcylinders=0x7fffffffdc2c, pheads=0x7fffffffdc28,
    psectors=0x7fffffffdc24) at block.c:1203
#4  0x000000000042b90f in bdrv_guess_geometry (bs=0x11277c0,
pcyls=0x7fffffffdc7c, pheads=0x7fffffffdc78,
    psecs=0x7fffffffdc74) at block.c:1250
#5  0x00000000005707c1 in ide_init_drive (s=0x1c936f0, bs=0x11277c0,
version=0x0, serial=0x0)
    at /home/ben/local/src/qemu/hw/ide/core.c:2522
#6  0x0000000000573762 in ide_drive_initfn (dev=0x15afb20) at
/home/ben/local/src/qemu/hw/ide/qdev.c:137
#7  0x0000000000480328 in qdev_init (dev=0xa) at
/home/ben/local/src/qemu/hw/qdev.c:281
#8  0x000000000048039a in qdev_init_nofail (dev=0xa) at
/home/ben/local/src/qemu/hw/qdev.c:372
#9  0x00000000005739fc in ide_create_drive (bus=<value optimized out>,
unit=0, drive=0x1127720)
    at /home/ben/local/src/qemu/hw/ide/qdev.c:104
#10 0x0000000000574206 in pci_ide_create_devs (dev=0x1c93410,
hd_table=<value optimized out>)
    at /home/ben/local/src/qemu/hw/ide/pci.c:438
#11 0x000000000057489b in pci_piix3_ide_init (bus=<value optimized
out>, hd_table=0x7fffffffdda0,
    devfn=<value optimized out>) at /home/ben/local/src/qemu/hw/ide/piix.c:177
#12 0x00000000005aaf84 in pc_init1 (ram_size=<value optimized out>,
boot_device=<value optimized out>,
    kernel_filename=<value optimized out>, kernel_cmdline=<value
optimized out>,
    initrd_filename=0x18 <Address 0x18 out of bounds>,
cpu_model=<value optimized out>, pci_enabled=1, kvmclock_enabled=1)
    at /home/ben/local/src/qemu/hw/pc_piix.c:143
#13 0x00000000005ab208 in pc_init_pci (ram_size=10,
boot_device=0x7fffffffd890 "", kernel_filename=0x7fffffffd810 "",
    kernel_cmdline=0xffffffffffffffff <Address 0xffffffffffffffff out
of bounds>, initrd_filename=0x0,
    cpu_model=0x4bf2 <Address 0x4bf2 out of bounds>) at
/home/ben/local/src/qemu/hw/pc_piix.c:199
#14 0x0000000000546d8b in main (argc=<value optimized out>,
argv=0x7fffffffe1a8, envp=<value optimized out>)
    at /home/ben/local/src/qemu/vl.c:3057

I configured with `./configure --target-list=x86_64-softmmu` and had
following output:
Install prefix    /usr/local
BIOS directory    /usr/local/share/qemu
binary directory  /usr/local/bin
config directory  /usr/local/etc
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /home/ben/local/src/qemu
C compiler        gcc
Host C compiler   gcc
CFLAGS            -O2 -g
QEMU_CFLAGS       -Werror -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing  -fstack-protector-all
-Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration
-Wold-style-definition -Wtype-limits
LDFLAGS           -Wl,--warn-common -m64 -g
make              make
install           install
host CPU          x86_64
host big endian   no
target list       x86_64-softmmu
tcg debug enabled no
Mon debug enabled no
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
-Werror enabled   yes
SDL support       yes
curses support    yes
curl support      yes
check support     no
mingw32 support   no
Audio drivers     oss
Extra audio cards ac97 es1370 sb16 hda
Block whitelist
Mixer emulation   no
VNC support       yes
VNC TLS support   yes
VNC SASL support  no
VNC JPEG support  yes
VNC PNG support   yes
VNC thread        no
xen support       no
brlapi support    no
bluez  support    no
Documentation     yes
NPTL support      yes
GUEST_BASE        yes
PIE user targets  no
vde support       no
IO thread         no
Linux AIO support yes
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
fdt support       no
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
uuid support      yes
vhost-net support no
Trace backend     nop
Trace output file trace-<pid>
spice support     no
rbd support       no
xfsctl support    no
nss used          no
OpenGL support    yes

Let me know if you need more info.
-Ben

[Qemu-devel] Re: [regression] configure: add opengl detection

[Michael Walle]

Hi Benjamin,

> Let me know if you need more info.

what happens if you configure with

./configure --target-list=x86_64-softmmu --disable-opengl


-- 
  Michael

[Qemu-devel] Re: [regression] configure: add opengl detection

[Benjamin Poirier]

On Mon, Apr 4, 2011 at 6:13 PM, Michael Walle <michael@walle.cc> wrote:
> Hi Benjamin,
>
>> Let me know if you need more info.
>
> what happens if you configure with
>
> ./configure --target-list=x86_64-softmmu --disable-opengl
>

Works as usual.
The problem I'm facing stems from linking to libGL and memory
protection issues. The particular system I ran this on has the binary
nvidia driver and its companion libGL.so.260.19.44. As such I'd take
no offense if we wave it off as a "problem in the unsupported binary
drivers" and I'll be satisfied configuring with no opengl on that
system.

Nevertheless, I did investigate about what's happening a little
further to clearly show that the problem is on nvidia's side.
1) as stated earlier, qemu segfaults when linked with the opengl libraries.

2) if I start qemu under gdb and configure it not to stop on SIGUSR2
(as I had omitted before; handle SIGUSR2 nostop noprint), qemu runs
ok. Same goes for strace.

3) if we enable /proc/sys/debug/exception-trace, the kernel printks:
    qemu-system-x86[15693]: segfault at 10c7820 ip 00000000010c7820 sp
00007fff71e334c8 error 15

10c7820 is the faulting address. Looking at the core file, we see that
10c7820 is the famous code_gen_prologue:

Program terminated with signal 11, Segmentation fault.
#0  0x00000000010c7820 in code_gen_prologue ()

(gdb) x /20i code_gen_prologue
=> 0x10c7820 <code_gen_prologue>:	push   %rbp
   0x10c7821 <code_gen_prologue+1>:	push   %rbx
   0x10c7822 <code_gen_prologue+2>:	push   %r12
   0x10c7824 <code_gen_prologue+4>:	push   %r13
[...]

By adding some debug code to map_exec() and adding a sigsegv handler
(that prints /proc/self/maps) I can see that code_gen_prologue is
adequately mprotect()'ed PROT_EXEC. Come time to jump into it from
cpu_exec(), that map is no longer there, the page is not executable,
and qemu crashes with a segfault.

Here is my debug output:
[...]
0091a000-01125000 rw-p 00000000 00:00 0
[...]
Will now map_exec 0x10c7820
Running mprotect 0x10c7000
Result: 0
[...]
0091a000-010c7000 rw-p 00000000 00:00 0
010c7000-010c8000 rwxp 00000000 00:00 0
010c8000-01125000 rw-p 00000000 00:00 0
[...]
Got SIGSEGV at address: 0x10c7820
[...]
0091a000-01125000 rw-p 00000000 00:00 0

I suspect that the nvidia libraries are messing with memory
protection. A look at objdump -R /usr/lib/libGL.so.1 indicates it does
need the symbol mprotect(). I tried to confirm this. Using a kernel
tracer (ftrace, perf or lttng), I can see that there are usually over
500 mprotect system calls before qemu crashes, including this
interesting combination (ftrace output):
 qemu-system-x86-21216 [002] 87794.633373: sys_mprotect(start:
10c7000, len: 1000, prot: 7)
 qemu-system-x86-21216 [000] 87794.806065: sys_mprotect(start: 400000,
len: 2f1000, prot: 7)
 qemu-system-x86-21216 [000] 87794.806079: sys_mprotect(start: 8f0000,
len: 835000, prot: 3)

With prot: 3 (read, write) it is essentially undoing what was done
100+ ms. earlier. In order to track down exactly where that call comes
from I tried using an LD_PRELOAD wrapper around glibc's mprotect() -
source for the wrapper here: https://gist.github.com/905600
When I do that, qemu doesn't crash anymore. ftrace reports the number
of mprotect calls is down to 123 and the odd combination is no longer
present. I can put the wrapper code within qemu itself and forgo
LD_PRELOAD, result is the same - no crash.

I would've like to show the weird mprotect call coming out of libGL or
libnvidia-whatever so we could point the finger to nvidia, but alas.
I'm at a loss as to why it doesn't crash under gdb, strace or with a
wrapper. If anyone has thoughts on that, I'm all ears.

Thanks,
-Ben

>
> --
>  Michael
>

[Qemu-devel] Re: [regression] configure: add opengl detection

[Michael Walle]

Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
> Works as usual.
> The problem I'm facing stems from linking to libGL and memory
> protection issues. The particular system I ran this on has the binary
> nvidia driver and its companion libGL.so.260.19.44. As such I'd take
> no offense if we wave it off as a "problem in the unsupported binary
> drivers" and I'll be satisfied configuring with no opengl on that
> system.

I would also be happy with opengl disabled by default. It is only used for one 
hardware model (milkymist-tmu2.c) atm. I don't think its worth that this 
potentially breaks qemu for lots of users. What do you think?

-- 
Michael

[Qemu-devel] Re: [regression] configure: add opengl detection

[Alexander Graf]

On 07.04.2011, at 23:35, Michael Walle wrote:

> Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
>> Works as usual.
>> The problem I'm facing stems from linking to libGL and memory
>> protection issues. The particular system I ran this on has the binary
>> nvidia driver and its companion libGL.so.260.19.44. As such I'd take
>> no offense if we wave it off as a "problem in the unsupported binary
>> drivers" and I'll be satisfied configuring with no opengl on that
>> system.
> 
> I would also be happy with opengl disabled by default. It is only used for one 
> hardware model (milkymist-tmu2.c) atm. I don't think its worth that this 
> potentially breaks qemu for lots of users. What do you think?

I tend to agree. We should probably default to disable opengl support. Users who really need that one particular board can enable it manually.


Alex

[Qemu-devel] Re: [regression] configure: add opengl detection

[Benjamin Poirier]

On 07/04/11 05:35 PM, Michael Walle wrote:
> Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
>> Works as usual.
>> The problem I'm facing stems from linking to libGL and memory
>> protection issues. The particular system I ran this on has the binary
>> nvidia driver and its companion libGL.so.260.19.44. As such I'd take
>> no offense if we wave it off as a "problem in the unsupported binary
>> drivers" and I'll be satisfied configuring with no opengl on that
>> system.
> 
> I would also be happy with opengl disabled by default. It is only used for one 
> hardware model (milkymist-tmu2.c) atm. I don't think its worth that this 
> potentially breaks qemu for lots of users. What do you think?
> 

I also have a system with binary ati drivers and it's ok. Perhaps other
people with the binary nvidia driver could comment?

[Qemu-devel] Re: [regression] configure: add opengl detection

[Edgar E. Iglesias]

On Thu, Apr 07, 2011 at 11:35:47PM +0200, Michael Walle wrote:
> Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
> > Works as usual.
> > The problem I'm facing stems from linking to libGL and memory
> > protection issues. The particular system I ran this on has the binary
> > nvidia driver and its companion libGL.so.260.19.44. As such I'd take
> > no offense if we wave it off as a "problem in the unsupported binary
> > drivers" and I'll be satisfied configuring with no opengl on that
> > system.
> 
> I would also be happy with opengl disabled by default. It is only used for one 
> hardware model (milkymist-tmu2.c) atm. I don't think its worth that this 
> potentially breaks qemu for lots of users. What do you think?

I agree, FWIW I've already got a couple of reports regarding the same
problem.

Cheers

[Qemu-devel] Re: [regression] configure: add opengl detection

[Michael Walle]

Am Freitag 08 April 2011, 12:00:32 schrieb Edgar E. Iglesias:
> On Thu, Apr 07, 2011 at 11:35:47PM +0200, Michael Walle wrote:
> > Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
> > > Works as usual.
> > > The problem I'm facing stems from linking to libGL and memory
> > > protection issues. The particular system I ran this on has the binary
> > > nvidia driver and its companion libGL.so.260.19.44. As such I'd take
> > > no offense if we wave it off as a "problem in the unsupported binary
> > > drivers" and I'll be satisfied configuring with no opengl on that
> > > system.
> > 
> > I would also be happy with opengl disabled by default. It is only used
> > for one hardware model (milkymist-tmu2.c) atm. I don't think its worth
> > that this potentially breaks qemu for lots of users. What do you think?
> 
> I agree, FWIW I've already got a couple of reports regarding the same
> problem.
> 
> Cheers

OTOH, a milkymist team member is worried that distributions would just build 
the QEMU package with the default options and all will ship qemu-system-lm32 
without opengl.

What do you think about disabling opengl by default except for lm32 targets?

-- 
Michael

Re: [Qemu-devel] Re: [regression] configure: add opengl detection

[Alexander Graf]

On 08.04.2011, at 23:13, Michael Walle wrote:

> Am Freitag 08 April 2011, 12:00:32 schrieb Edgar E. Iglesias:
>> On Thu, Apr 07, 2011 at 11:35:47PM +0200, Michael Walle wrote:
>>> Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
>>>> Works as usual.
>>>> The problem I'm facing stems from linking to libGL and memory
>>>> protection issues. The particular system I ran this on has the binary
>>>> nvidia driver and its companion libGL.so.260.19.44. As such I'd take
>>>> no offense if we wave it off as a "problem in the unsupported binary
>>>> drivers" and I'll be satisfied configuring with no opengl on that
>>>> system.
>>> 
>>> I would also be happy with opengl disabled by default. It is only used
>>> for one hardware model (milkymist-tmu2.c) atm. I don't think its worth
>>> that this potentially breaks qemu for lots of users. What do you think?
>> 
>> I agree, FWIW I've already got a couple of reports regarding the same
>> problem.
>> 
>> Cheers
> 
> OTOH, a milkymist team member is worried that distributions would just build 
> the QEMU package with the default options and all will ship qemu-system-lm32 
> without opengl.
> 
> What do you think about disabling opengl by default except for lm32 targets?

I would really like to see some more logic behind target library requirements and actual linking anyway. On PPC for example, we link with libfdt to do device tree modifications, but link with libfdt on x86 as well when it's detected. Same goes for the xen libraries.

Being more clever about target requirements would certainly be useful. For now, I'd disable OpenGL by default though and then follow up with a patch to add the cleverness :).


Alex

Re: [Qemu-devel] Re: [regression] configure: add opengl detection

[Edgar E. Iglesias]

On Sat, Apr 09, 2011 at 02:04:07AM +0200, Alexander Graf wrote:
> 
> On 08.04.2011, at 23:13, Michael Walle wrote:
> 
> > Am Freitag 08 April 2011, 12:00:32 schrieb Edgar E. Iglesias:
> >> On Thu, Apr 07, 2011 at 11:35:47PM +0200, Michael Walle wrote:
> >>> Am Mittwoch 06 April 2011, 16:13:58 schrieb Benjamin Poirier:
> >>>> Works as usual.
> >>>> The problem I'm facing stems from linking to libGL and memory
> >>>> protection issues. The particular system I ran this on has the binary
> >>>> nvidia driver and its companion libGL.so.260.19.44. As such I'd take
> >>>> no offense if we wave it off as a "problem in the unsupported binary
> >>>> drivers" and I'll be satisfied configuring with no opengl on that
> >>>> system.
> >>> 
> >>> I would also be happy with opengl disabled by default. It is only used
> >>> for one hardware model (milkymist-tmu2.c) atm. I don't think its worth
> >>> that this potentially breaks qemu for lots of users. What do you think?
> >> 
> >> I agree, FWIW I've already got a couple of reports regarding the same
> >> problem.
> >> 
> >> Cheers
> > 
> > OTOH, a milkymist team member is worried that distributions would just build 
> > the QEMU package with the default options and all will ship qemu-system-lm32 
> > without opengl.
> > 
> > What do you think about disabling opengl by default except for lm32 targets?
> 
> I would really like to see some more logic behind target library requirements and actual linking anyway. On PPC for example, we link with libfdt to do device tree modifications, but link with libfdt on x86 as well when it's detected. Same goes for the xen libraries.
> 
> Being more clever about target requirements would certainly be useful. For now, I'd disable OpenGL by default though and then follow up with a patch to add the cleverness :).

Yep, that sounds good.

Cheers

[Qemu-devel] [PATCH] configure: disable opengl per default

[Michael Walle]

There is a bug in nvidia's binary GPU driver, which causes a segmentation
fault if linked to libGL.

Signed-off-by: Michael Walle <michael@walle.cc>
---
 configure |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 2bb3faa..be40a31 100755
--- a/configure
+++ b/configure
@@ -177,6 +177,7 @@ spice=""
 rbd=""
 smartcard=""
 smartcard_nss=""
+opengl="no"
 
 # parse CC options first
 for opt do
-- 
1.7.2.3

[Qemu-devel] Re: [PATCH] configure: disable opengl per default

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On 2011-04-09 23:13, Michael Walle wrote:
> There is a bug in nvidia's binary GPU driver, which causes a segmentation
> fault if linked to libGL.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  configure |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/configure b/configure
> index 2bb3faa..be40a31 100755
> --- a/configure
> +++ b/configure
> @@ -177,6 +177,7 @@ spice=""
>  rbd=""
>  smartcard=""
>  smartcard_nss=""
> +opengl="no"
>  
>  # parse CC options first
>  for opt do

I stumbled over this issue as well, but was unhappy about simply
disabling OpenGL without understanding what goes wrong. Still, I can't
provide a better solution yet, just some maybe helpful insights:

...
00908000-0134f000 rw-p 00000000 00:00 0 [heap]
41944000-43944000 rwxp 00000000 00:00 0
...

That's an extract of /proc/$QEMU_PID/maps with -lGL, and below without it:

00908000-010bd000 rw-p 00000000 00:00 0
010bd000-010be000 rwxp 00000000 00:00 0
010be000-01335000 rw-p 00000000 00:00 0 [heap]
40514000-42514000 rwxp 00000000 00:00 0

IOW, we are lacking the executable code_gen_prologue page. This problem
behaves like a heisenbug, ie. it disappears here when I run qemu in gdb
or under strace. But ftrace confirms that the qemu process issues
mprotect to make the whole heap non-executable after setting up that TCG
buffer - it just doesn't tell me which part of qemu is responsible for this.

Note that I'm still forced to use this wonderful binary nvidia stuff.

Anyone any ideas?
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Qemu-devel] [PATCH] configure: disable opengl per default

[Aurelien Jarno]

On Sat, Apr 09, 2011 at 11:13:20PM +0200, Michael Walle wrote:
> There is a bug in nvidia's binary GPU driver, which causes a segmentation
> fault if linked to libGL.
> 
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
>  configure |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Thanks, applied.

> diff --git a/configure b/configure
> index 2bb3faa..be40a31 100755
> --- a/configure
> +++ b/configure
> @@ -177,6 +177,7 @@ spice=""
>  rbd=""
>  smartcard=""
>  smartcard_nss=""
> +opengl="no"
>  
>  # parse CC options first
>  for opt do
> -- 
> 1.7.2.3
> 
> 
> 

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net