Getting qemu plugins working on windows

[Greg Manning]

Hello,

Currently, qemu plugin support only works in Linux and I would like to get qemu 
plugins working on
Windows. I have had some success experimenting with this locally (based on some 
previous work by
Yonggang Luo, see below), but would like to gauge opinion before I commit to 
suggesting a solution.

The overall structure of how plugins work is this:

1. qemu executable loads plugin.so.
2. plugin.so defines a function qemu_plugin_install, which qemu looks up, and 
calls.
during that function call plugin.so might call some of the qemu_plugin_* 
functions that the host
executable has implementations of. plugin.so is compiled with unresolved 
references to these functions,
and they get linked up at dll load time.

Windows doesn't let you do such on-the-fly load time linking. You need a dll 
import library, which is
specific to a particular host executable. The qemu project, however, has many 
executables, any
of which might want to load a given plugin.

Possible ways to get things working on Windows:

1. Make the dll import library. Possibly refactor the qemu plugin code into a 
single qemu_plugin.{so,dll},
   and then make the import library for that. I don't fully understand this 
system, and I'm still concerned
   it would be fragile (if qemu is recompiled, do I need to recompile all my 
plugins against the new
   version of the import library?)
2. Change the way plugins can access the available host API. We could define a 
typedef struct full
   of function pointers and have one of those passed to the plugin in 
qemu_plugin_install. The plugin
   can use this to populate some global variable, and use it to call the 
necessary functions.
3. Have windows plugins export a bunch of qemu_plugin_* function pointers, and 
have the plugin loader
   code find all the pointers and point them at real functions. This has the 
benefit (in some
   simple cases) of not needing any code changes on the plugin side. However, 
it means qemu-plugin.h
   declares new symbols on the plugin side, and you have to be careful to only 
declare them once in
   the plugin.

   Having real functions on linux and function pointers on windows is a neat 
trick in C, but might
   cause subtle differences for systems that automatically generate bindings 
for other languages -
   functions will always be set, but function pointers might be behind some 
nullable type wrapper.

I'm inclined toward the second option as being the neatest, but it does involve 
the most API churn
(though both styles could be maintained for some time, just only the newer 
style would work on
windows).

Previously, some work was done to try and get windows plugins working in 2020: 
[1], [2].
This work was never merged in. I have emailed the original author to try to 
find out what happened
(and CCed them here). This work took the 3rd option from above - defining a set 
of function pointers
in place of the linked up function declarations.

Does anyone have strong feelings about how to solve this?

[1]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg744980.html
[2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg749982.html

Regards,

Greg Manning





--

Follow Rapita Systems on 
LinkedIn<https://www.linkedin.com/company/rapita-systems?utm_source=rs_email_sig>