All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
	qemu-devel@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH RFC 00/10] qapi: remove all TARGET_* conditionals from the schema
Date: Mon, 12 May 2025 19:38:07 +0100	[thread overview]
Message-ID: <aCJADz2WhyOBYy3H@redhat.com> (raw)
In-Reply-To: <874ixt2e2l.fsf@pond.sub.org>

On Sat, May 10, 2025 at 08:08:02AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, May 09, 2025 at 03:43:30PM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> > Even if we had a QAPI schema that didn't vary per target, this is
> >> > repeated probing is tricky to avoid when we have completely independant
> >> > binaries. We would need QEMU to have some internal "build id", so that
> >> > we could detect that all binaries came from the same build, to let us
> >> > avoid re-probing each binary.
> >> 
> >> Back when I created QAPI/QMP introspection, I floated the idea to put
> >> something into the QMP greeting to enable safe caching.  Libvirt
> >> developers told me they didn't need that.  I don't remember the details,
> >> but I guess the cache invalidation they already had was deemed good
> >> enough.
> >
> > I don't recall that discussion, but I would think the problem is
> > that we probe much more than just QMP schema. Actually thinking
> > about it, the fact that we probe more than just QMP schema means
> > my idea of probing once and getting the answer for all targets
> > may not be practical. Some of the query-xxx  commands we run will
> > likely need to know the target.
> 
> Yes.
> 
> We could split the cache along validity conditions.  Possibly worth the
> extra complexity if expensive probes then live longer in their cache.
> 
> I'd love to have a list of probes libvirt runs and why.

We don't record the 'why' I'm afraid, so answer the 'why' is pretty
much a case of having to read the code :-(

The list of probes is also somewhat metadata driven, starting
from:

 https://gitlab.com/libvirt/libvirt/-/blob/6ff8d08777ebbcb9a1e11534c3a3341fbf0343e8/src/qemu/qemu_capabilities.c?page=6#L5718

you would have to then work backwards for each virQMEUCapsProbeQMP
method we call.

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



  reply	other threads:[~2025-05-12 18:38 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08 13:58 [PATCH RFC 00/10] qapi: remove all TARGET_* conditionals from the schema Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 01/10] qapi: expose rtc-reset-reinjection command unconditionally Daniel P. Berrangé
2025-05-10  9:57   ` Markus Armbruster
2025-05-12 18:33     ` Daniel P. Berrangé
2025-05-13  0:54       ` Pierrick Bouvier
2025-05-13  1:09         ` Pierrick Bouvier
2025-05-13  7:55       ` Markus Armbruster
2025-05-08 13:58 ` [PATCH 02/10] qapi: expand docs for SEV commands Daniel P. Berrangé
2025-05-13 12:06   ` Markus Armbruster
2025-05-13 12:21     ` Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 03/10] qapi: make SEV commands unconditionally available Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 04/10] qapi: expose query-gic-capability command unconditionally Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 05/10] qapi: make SGX commands unconditionally available Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 06/10] qapi: make Xen event " Daniel P. Berrangé
2025-05-08 15:01   ` Philippe Mathieu-Daudé
2025-05-08 17:48     ` David Woodhouse
2025-05-08 17:53       ` Daniel P. Berrangé
2025-05-08 19:08         ` David Woodhouse
2025-05-08 13:58 ` [PATCH 07/10] qapi: remove the misc-target.json file Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 08/10] qapi: Make CpuModelExpansionInfo::deprecated-props optional and generic Daniel P. Berrangé
2025-05-13 12:38   ` Markus Armbruster
2025-05-13 12:41     ` Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 09/10] qapi: make most CPU commands unconditionally available Daniel P. Berrangé
2025-05-08 20:55   ` Pierrick Bouvier
2025-05-13 12:44   ` Markus Armbruster
2025-05-13 16:37     ` Daniel P. Berrangé
2025-05-08 13:58 ` [PATCH 10/10] qapi: make s390x specific " Daniel P. Berrangé
2025-05-08 14:56 ` [PATCH RFC 00/10] qapi: remove all TARGET_* conditionals from the schema Philippe Mathieu-Daudé
2025-05-08 14:58   ` Daniel P. Berrangé
2025-05-08 21:09 ` Pierrick Bouvier
2025-05-09  9:02   ` Daniel P. Berrangé
2025-05-09 13:43     ` Markus Armbruster
2025-05-09 13:56       ` Daniel P. Berrangé
2025-05-10  6:08         ` Markus Armbruster
2025-05-12 18:38           ` Daniel P. Berrangé [this message]
2025-05-10  9:28 ` Markus Armbruster
2025-05-12 18:39   ` Daniel P. Berrangé
2025-05-12 20:09     ` Pierrick Bouvier
2025-05-13  7:59       ` Markus Armbruster
2025-05-13 14:36         ` Pierrick Bouvier
2025-05-13 14:55           ` Daniel P. Berrangé

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=aCJADz2WhyOBYy3H@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --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.