qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] object: add more commands to preconfig mode
Date: Tue, 08 Jun 2021 15:45:19 +0200	[thread overview]
Message-ID: <87czswzd00.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210511153938.505687-1-pbonzini@redhat.com> (Paolo Bonzini's message of "Tue, 11 May 2021 11:39:38 -0400")

This has been committed already, but here goes anyway...

Paolo Bonzini <pbonzini@redhat.com> writes:

> Creating and destroying QOM objects does not require a fully constructed
> machine.  Allow running object-add and object-del before machine
> initialization has concluded.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Well, *some* QOM objects do require a fully constructed machine (or else
device_add should be allowd in preconfig).  object-add creates only
*user-creatable* QOM objects (the ones implementing
TYPE_USER_CREATABLE).

How can we be sure the user-creatable objects we have don't require a
fully constructed machine?

What stops future user-creatable objects from requiring one?  Would be
bad, because they'd work fine in casual testing, and explode when used
in the (somewhat exotic) preconfig state.

In case it helps, let me list the user-creatable QOM types.  QMP command

    {"execute": "qom-list-types", "arguments": {"implements": "qtest"}}

gets us the ones compiled into a specific system emulator.  My x86_64
coughs up

    "authz-list"
    "authz-list-file"
    "authz-pam"
    "authz-simple"
    "can-bus"
    "can-host-socketcan"
    "colo-compare"
    "cryptodev-backend"
    "cryptodev-backend-builtin"
    "cryptodev-vhost-user"
    "dbus-vmstate"
    "filter-buffer"
    "filter-dump"
    "filter-mirror"
    "filter-redirector"
    "filter-replay"
    "filter-rewriter"
    "input-barrier"
    "input-linux"
    "iothread"
    "memory-backend-file"
    "memory-backend-memfd"
    "memory-backend-ram"
    "pr-manager-helper"
    "qtest"
    "rng-builtin"
    "rng-egd"
    "rng-random"
    "secret"
    "secret_keyring"
    "sev-guest"
    "throttle-group"
    "tls-cipher-suites"
    "tls-creds-anon"
    "tls-creds-psk"
    "tls-creds-x509"
    "x-remote-object"

I could do this for all system emulators, but I prefer differently
boring; code inspection finds two more:

    "pef-guest"
    "s390-pv-guest"



      parent reply	other threads:[~2021-06-08 13:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 15:39 [PATCH] object: add more commands to preconfig mode Paolo Bonzini
2021-06-07 14:18 ` Daniel P. Berrangé
2021-06-08 13:45 ` Markus Armbruster [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=87czswzd00.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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).