From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: "Akihiko Odaki" <akihiko.odaki@gmail.com>,
"Marc-André Lureau" <marcandre.lureau@gmail.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Thomas Huth" <thuth@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: tests/qtest: Is vnc-display-test supposed to work on Darwin?
Date: Thu, 19 Jan 2023 12:00:41 +0000 [thread overview]
Message-ID: <Y8kw6X6keB5l53nl@redhat.com> (raw)
In-Reply-To: <fe0f448c-6a8f-9830-208b-5e1c52e5e203@linaro.org>
On Thu, Jan 19, 2023 at 12:49:48PM +0100, Philippe Mathieu-Daudé wrote:
> On 19/1/23 12:33, Daniel P. Berrangé wrote:
> > On Thu, Jan 19, 2023 at 12:21:58PM +0100, Philippe Mathieu-Daudé wrote:
> > > On 19/1/23 12:16, Daniel P. Berrangé wrote:
> > > > On Thu, Jan 19, 2023 at 12:01:18PM +0100, Philippe Mathieu-Daudé wrote:
> > > > > On 5/12/22 08:51, Marc-André Lureau wrote:
> > > > > > On Fri, Dec 2, 2022 at 1:51 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > > > > > >
> > > > > > > The vnc-display-test is failing on Darwin:
> > > > > > >
> > > > > > > tests/qtest/vnc-display-test:45038): ERROR **: 10:42:35.488: vnc-error:
> > > > > > > Unsupported auth type 17973672
> > > > > >
> > > > > > It is supposed to pass. Can you share more details? It doesn't look
> > > > > > like an endianness issue, at first sight..
> > > > >
> > > > > Adding '-trace vnc*' and setting _VNC_DEBUG in "vnc.h" I get:
> > >
> > > > > Bail out! FATAL-ERROR: vnc-error: Unsupported auth type 5489072
> > > >
> > > > ^^^^ This specific message is comnig from the gtk-vnc client rather
> > > > than QEMU
> > > >
> > > > Still doesn't tell us if the flaw is server or client side. The
> > > > logs from QEMU are insufficient. In theory it should be reporting
> > > > auth type == 0 though, for 'no auth' configs.
> > >
> > > > > Does that help? What else can I do to gather more info?
> > > >
> > > > Modify vnc-display-test.c to call vnc_util_set_debug(TRUE);
> > > > before vnc_connection_new(), to get the gtk-vnc debug logs
> > > > to stderr too.
> > > Here you go:
> > >
> > > vnc_server_dpy_recreate VNC server dpy recreate dpy=0x1588b8000 size=640x384
> > > fmt=537004168
> > > vnc_auth_init VNC auth init state=0x1588b8000 websock=0 auth=1 subauth=0
> > > vnc_auth_init VNC auth init state=0x1588b8000 websock=1 auth=1 subauth=0
> > > vnc_client_connect VNC client connect state=0x1484b0000 ioc=0x152e667f0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Init VncConnection=0x14f0168b0
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Init
> > > VncConnection=0x14f0168b0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Thinking about auth type 1
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Thinking about auth type
> > > 1
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Decided on auth type 1
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Decided on auth type 1
> >
> > So here we set conn->auth_type == 1
> >
> >
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Open fd=4
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open fd=4
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Open coroutine starting
> > > gtk-vnc-DEBUG: 12:20:30.482: ../src/vncconnection.c Open coroutine starting
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Started background coroutine
> > > gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Started background
> > > coroutine
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Connecting to FD 4
> > > gtk-vnc-DEBUG: 12:20:30.484: ../src/vncconnection.c Connecting to FD 4
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 16
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Emit main context 16
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Protocol initialization
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Protocol initialization
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Schedule greeting timeout
> > > 0x14f0155e0
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Schedule greeting
> > > timeout 0x14f0155e0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Remove timeout 0x14f0155e0
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Remove timeout
> > > 0x14f0155e0
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Server version: 3.8
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Server version: 3.8
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Sending full greeting
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Sending full greeting
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Using version: 3.8
> > > gtk-vnc-DEBUG: 12:20:30.485: ../src/vncconnection.c Using version: 3.8
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Possible auth 1
> > > gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Possible auth 1
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Emit main context 14
> > > gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Emit main context 14
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Waiting for auth type
> > > gtk-vnc-DEBUG: 12:20:30.589: ../src/vncconnection.c Waiting for auth type
> > > # gtk-vnc-DEBUG: ../src/vncconnection.c Choose auth 10486192
> >
> > Here we've read conn->auth_type and got back 10486192 nonsense instead
> > of 1.
> >
> > Interestingly this value is differetn from the previous debug log
> > which reported 5489072, so i guess we're getting garbage here for
> > unknown reasons.
> >
> > This looks like a gtk-vnc problem rather than QEMU.
> >
> > I'm a little worried that perhaps the gtk-vnc ucontext coroutine backend
> > is broken on macOS
> >
> > What coroutine backend does QEMU end up using on macOS ? Is it the
> > sigaltstack one ?
>
> Block layer support
> coroutine backend : sigaltstack
> coroutine pool : YES
>
> When trying the coroutine options, with --with-coroutine=windows:
>
> ERROR: 'windows' coroutine backend only valid for Windows
>
> :) and with --with-coroutine=ucontext I get:
>
> ERROR: 'ucontext' backend requested but makecontext not available
>
> config.log hints:
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ucontext.h:51:2:
> error: The deprecated ucontext routines require _XOPEN_SOURCE to be defined
> #error The deprecated ucontext routines require _XOPEN_SOURCE to be defined
> ^
>
> Adding _XOPEN_SOURCE to QEMU_CFLAGS:
>
> warning: 'makecontext' is deprecated: first deprecated in macOS 10.6 - No
> longer supported [-Wdeprecated-declarations]
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ucontext.h:41:6:
> note: 'makecontext' has been explicitly marked deprecated here
> void makecontext(ucontext_t *, void (*)(), int, ...);
> ^
>
> So to detect makecontext() I have to add
> --extra-cflags=-mmacosx-version-min=10.5 but then linking fails with
> multiple "$LIBNAME was built for newer macOS version (13.0) than being
> linked (11.0)".
Yes, ucontext has been deprecated forever on macOS, but in practice it
has still been functional if you define _XOPEN_SOURCE, which is what
gtk-vnc has done traditionally.
I presume this is on the aarch64 macOS though, and so all bets are off
wrt ucontext backend unless someone knows it works correctly with the
m1 port. I fear that's not the case though, given the wierd error
scenario we're hitting in gtk-vnc.
I might need to add a sigaltstack impl to gtk-vnc
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-01-19 12:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 9:49 tests/qtest: Is vnc-display-test supposed to work on Darwin? Philippe Mathieu-Daudé
2022-12-05 7:51 ` Marc-André Lureau
2023-01-19 11:01 ` Philippe Mathieu-Daudé
2023-01-19 11:16 ` Daniel P. Berrangé
2023-01-19 11:21 ` Philippe Mathieu-Daudé
2023-01-19 11:33 ` Daniel P. Berrangé
2023-01-19 11:49 ` Philippe Mathieu-Daudé
2023-01-19 12:00 ` Daniel P. Berrangé [this message]
2023-01-19 14:14 ` Daniel P. Berrangé
2023-01-19 11:29 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8kw6X6keB5l53nl@redhat.com \
--to=berrange@redhat.com \
--cc=akihiko.odaki@gmail.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.