All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Florian Hofhammer <florian.hofhammer@epfl.ch>,
	qemu-devel@nongnu.org,
	Richard Henderson <richard.henderson@linaro.org>,
	Laurent Vivier <laurent@vivier.eu>, Warner Losh <imp@bsdimp.com>
Subject: Re: New capabilities for plugins
Date: Tue, 5 Aug 2025 17:12:14 +0100	[thread overview]
Message-ID: <aJItXiCESEAPDzec@redhat.com> (raw)
In-Reply-To: <87tt2n5az1.fsf@draig.linaro.org>

On Mon, Aug 04, 2025 at 05:05:06PM +0100, Alex Bennée wrote:
> Florian Hofhammer <florian.hofhammer@epfl.ch> writes:
> 
> > Hello,
> 
> (Added the *-user MAINTAINERS to the CC)
> > More specifically, the "vcpu_syscall_cb" and "vcpu_syscall_ret"
> > callbacks already allow me to instrument syscall translation entry and
> > exit points. While the register read/write APIs also allow me to
> > modify register contents in my syscall callback implementations, there
> > is currently no good way to emulate a syscall myself in the plugin or
> > explicitly set the syscall return value (as it will be overwritten
> > with the original syscall's return value again, even if I set the
> > corresponding guest register).
> >
> > I was wondering whether the QEMU community would be open to extending
> > the plugin API so that a plugin can fully emulate a syscall without
> > the original syscall being executed by QEMU.
> 
> I will defer to the *-user maintainers here. One thing we are keen to
> avoid is plugins being used as a mechanism to work around the GPL
> requirements of QEMU itself. It would be useful if you could outline the
> use case for a plugin doing the emulation itself?

Yeah, this sounds like it is potentially going a step too far in enabling
fully out of tree extension of core QEMU functionality.

If something conceptually is in scope of the core QEMU codebase, then
IMHO, our plugin system should aim to avoid enabling external
implementations as far as is practical.  That was easy when plugins
were limited to observability, but the more we enable in terms of
state modification the wider pandora's box is opened.

Where to draw the line is a hard problem.

Excluding some undesirable features, may well force us to exclude some
potentially desirable plugin use cases at the same time, which may make
it impossible to keep everyone satisfied.

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 :|



  parent reply	other threads:[~2025-08-05 16:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-04 10:14 New capabilities for plugins Florian Hofhammer
2025-08-04 16:05 ` Alex Bennée
2025-08-05 13:22   ` Florian Hofhammer
2025-08-05 14:16     ` Alex Bennée
2025-08-05 14:30       ` Florian Hofhammer
2025-08-05 15:30         ` Alex Bennée
2025-08-21 16:02           ` Florian Hofhammer
2025-08-22  8:44             ` Alex Bennée
2025-08-26 14:37               ` Florian Hofhammer
2025-08-05 16:12   ` Daniel P. Berrangé [this message]
2025-08-21 15:58     ` Florian Hofhammer
2025-08-22  8:41       ` Alex Bennée
2025-08-04 17:01 ` Pierrick Bouvier

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=aJItXiCESEAPDzec@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=florian.hofhammer@epfl.ch \
    --cc=imp@bsdimp.com \
    --cc=laurent@vivier.eu \
    --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 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.