Anthony Liguori writes:
[...]
If you want to extend QEMU, then send proper patches. Adding random C files to
the build is unacceptable.
What do you mean by proper patches?
If you want to add "custom functionality" to QEMU, send a patch to upstream
QEMU.
See below.
The whole point of this is to ease the
process for the user to add custom guest-to-qemu interactions, so there is no
"proper implementation" here.
That's too vague as far as I'm concerned. The only reason I can see to have a
mechanism like this is 1) to avoid pushing stuff upstream and/or 2) to
circumvent QEMU licensing by shipping a separate file that the user includes
themselves.
AFAIK, GPL licensing restrictions only apply when the code is shipped in a
binary blob. If this is the case, the library is statically included in qemu, so
it must still comply with the licensing requirements of qemu. Still, take this
with a grain of salt as I'm not a licensing expert.
My motivation is more like 1 (I'll release the analyzer library I'm developing
once it's finished), but for the reasons stated below.
I see no reason to encourage either of these things. It also creates an
inevitable problem of internal API stability. What happens when the tree
changes and all of these "custom guest-to-qemu interactions" break?
You may claim that it's an unsupported interface, but what will actually happen
is that users will start depending on these custom features long after the
initial developer has stopped caring.
Blue Swirl already mentioned this can be used for testing qemu itself, while my
use case is coupled with the trace instrumentation features (I'll probably send
the first batch today).
In terms of supporting this mechanism, all backend code needs to live in
upstream QEMU. That's a hard requirement. No configure flags to pull in random
C files and no dlopens.
If you resent the series doing that, it'd be more likely to be merged but since
I don't think your intention is to push backend code into QEMU, I wonder whether
it's worth really merging this mechanism at all.
If this is just infrastructure that is only used by private forks, I don't think
it belongs upstream.
Well, both backdoor and trace instrumentation are implemented using the same
approach (a static library selected at compile-time). The user sets which events
to instrument in the "trace-events" file. This has the effect that the tracetool
script will not generate the tracing functions for those events, and instead the
user must provide the implementation for these events on a static library
provided at compile time.
The analyses one might want to perform are ad-hoc in nature. For example, some
recent work sent here did coverage analyses through ad-hoc modifications on the
core of qemu, I want to generate detailed traces of the guest code that is
executed (although only when certain conditions in the guest are met). There is
no silver bullet here, but the development of analyzers can be simplified by
letting users perform static instrumentation of the tracing events, which act as
regular tracing events otherwise.
In this environment, the backdoor is just a handy channel to let the guest
communicate with code on that analyzer library, like signalling semanticful
events of interest (e.g., I have a trivial linux kernel module that installs a
tracepoint callback in the process switch routine and passes that information
down to the analyzer library through the backdoor channel).
As these analyzes are ad-hoc in nature, I don't see any way other than providing
this extension functionality.