From: "Alex Bennée" <alex.bennee@linaro.org>
To: Greg Manning <gmanning@rapitasystems.com>
Cc: qemu-devel@nongnu.org, luoyonggang@gmail.com,
richard.henderson@linaro.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 0/1] Enable plugin support for windows
Date: Thu, 02 Nov 2023 14:24:30 +0000 [thread overview]
Message-ID: <87msvw44ip.fsf@draig.linaro.org> (raw)
In-Reply-To: <20231102110016.9494-1-gmanning@rapitasystems.com> (Greg Manning's message of "Thu, 2 Nov 2023 10:59:41 +0000")
(Add Paolo to cc for meson questions)
Greg Manning <gmanning@rapitasystems.com> writes:
> This patch enables plugin support on windows.
>
> qemu plugins on windows now correctly load/link the qemu_plugin_*
> symbols when they are loaded[1]. This works by creating a delay-loaded
> .lib file with dlltool[2], then linking the plugins against that to get
> them compiled. No messing around with function pointers required.
>
> The .lib file is created with "qemu.exe" as the name of the DLL.
> The only input to the creation of the .lib file is a list of
> qemu_plugin_* api symbol names.
>
> When the DLL is being loaded, it will fail to find qemu.exe[3], but
> the windows linker has a 'dll loading failed' hook you can put in the
> plugin.
>
> I've implemented this hook to check if the file that's failed to load is
> 'qemu.exe', and if so, substitute in a handle to the top-level
> executable. Symbol linking then continues in the normal way.
>
> As such, windows plugins work for me, and with minimal change to actual
> qemu code.
Excellent work - I'm glad you can make it work without having to hack
the rest of the plugins too much. I'm afraid I can't do much to test
this but overall I'm much happier to merge this.
However can we split the patches into slightly smaller chunks. Maybe
something like:
- add the QEMU_PLUGIN_API annotations
- introduce the windows linker bits
- filter the plugins that can't be built for windows
- flip the switch in configure to allow plugins to be built on Windows
Also what are we going to do for testing? Most qemu developers are using
POSIX systems so I'm worried about support bit rotting. We do have some
windows coverage in CI but currently only running qtest. There are some
"make check-tcg" tests which are softmmu but I suspect getting the
cross-compilers on windows would be a blocker. Do we know the state of
the avocado tests? We have some minimal testing there which could be
extended as all you need is avocado working and some binary images to
run. I've just posted a patch to update them:
Message-Id: <20231101135004.1572916-1-alex.bennee@linaro.org>
Date: Wed, 1 Nov 2023 13:50:03 +0000
Subject: [RFC PATCH] tests/avocado: update the tcg_plugins test
From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <alex.bennee@linaro.org>
> [1]: Except lockstep, which uses unix sockets. It could be changed to
> use another communication mechanism, but that felt outside what I'm
> trying to achieve here.
>
> [2]: This would be the first use of dlltool in qemu. Is that OK? do we
> need anything in meson to check it exists?
Paolo any comments on the meson bits?
>
> [3]: If qemu moved to a single executable model, and we got the name
> right when creating the .lib, then the dll hook would not be
> needed at all.
>
> Limitations/things I'm worried about
>
> * There is some amount of meson/Makefile tweaking going on here, and
> while what I've got works for me, I'm not very familiar with meson,
> and might not be doing things The Right Way.
>
> * plugin/FFI bindings authors would have to copy this hook themselves,
> or implement something equivalent. Also they need the
> qemu_plugin_api.lib file, which I think I've added to the set of
> installed files.
>
> * License for win32_linker.c - I'm happy to put this under whatever
> license seems most convenient. Given qemu-plugin.h is already GPL,
> all plugins will be GPL anyway.
While there may be private downstream plugins being used behind closed
doors we very much don't want to encourage binary only plugins so GPL is
fine.
> Greg Manning (1):
> plugins: enable plugins for windows
>
> configure | 9 ++----
> contrib/plugins/Makefile | 27 ++++++++++++++++--
> contrib/plugins/win32_linker.c | 34 +++++++++++++++++++++++
> include/qemu/qemu-plugin.h | 50 ++++++++++++++++++++++++++++++++--
> meson.build | 5 ++++
> plugins/meson.build | 17 ++++++++++++
> tests/plugin/meson.build | 14 ++++++++--
> 7 files changed, 141 insertions(+), 15 deletions(-)
> create mode 100644 contrib/plugins/win32_linker.c
>
> --
> 2.42.0
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
prev parent reply other threads:[~2023-11-02 14:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-02 10:59 [PATCH 0/1] Enable plugin support for windows Greg Manning
2023-11-02 10:59 ` [PATCH 1/1] plugins: enable plugins " Greg Manning
2023-11-02 14:24 ` Alex Bennée [this message]
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=87msvw44ip.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=gmanning@rapitasystems.com \
--cc=luoyonggang@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).