From: Damien Hedde <damien.hedde@greensocs.com>
To: qemu-devel@nongnu.org
Cc: "Damien Hedde" <damien.hedde@greensocs.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"David Hildenbrand" <david@redhat.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Peter Xu" <peterx@redhat.com>, "Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>
Subject: [RFC PATCH v5 0/3] Sysbus device generic QAPI plug support
Date: Tue, 24 May 2022 15:48:06 +0200 [thread overview]
Message-ID: <20220524134809.40732-1-damien.hedde@greensocs.com> (raw)
Hi all,
This series is about enabling to plug sysbus devices with
device_add QAPI command. I've put RFC because, there are several
options and I would like to know if you think the current version
is ok to be added in qemu.
Right now only a few sysbus device can be plugged using "-device"
CLI option and a custom plugging mechanism. A machine defines a
list of allowed/supported sysbus devices and provides some code to
handle the plug. For example, it sets up the memory map and irq
connections.
In order to configure a machine from scratch with qapi, we want to
cold plug sysbus devices to the _none_ machine with qapi commands
without requiring the machine to provide some specific per-device
support.
There are mostly 2 options (option 1 is in these patches). Note that
in any case this only applies to "user-creatable" device.
+ Option 1: Use the current plug mechanism by allowing any sysbus
device, without adding handle code in the machine.
+ Option 2: Add a boolean flag in the machine to allow to plug any
sysbus device. We can additionally differentiate the sysbus devices
requiring the legacy plug mechanism (with a flag, for example) and
the others.
The setup of the memory map and irq connections is not related to
the option choice above. We planned to rely on qapi commands to do
these operations. A new _sysbus-mmio-map_ command is proposed in this
series to setup the mapping. Irqs can already be connected using the
_qom-set_ command.
Alternatively we could probably add parameters/properties to device_add
to handle the memory map, but it looks more complicated to achieve.
Based-on: <20220519153402.41540-1-damien.hedde@greensocs.com>
( QAPI support for device cold-plug )
Note that it does not stricly require this to be merged, but this series
does not make much sense without the ability to cold plug with device_add
first.
Thanks for your feedback,
--
Damien
Damien Hedde (3):
none-machine: allow cold plugging sysbus devices
softmmu/memory: add memory_region_try_add_subregion function
add sysbus-mmio-map qapi command
qapi/qdev.json | 31 ++++++++++++++++++++++++++
include/exec/memory.h | 22 +++++++++++++++++++
hw/core/null-machine.c | 4 ++++
hw/core/sysbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++
softmmu/memory.c | 26 ++++++++++++++--------
5 files changed, 123 insertions(+), 9 deletions(-)
--
2.36.1
next reply other threads:[~2022-05-24 13:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 13:48 Damien Hedde [this message]
2022-05-24 13:48 ` [RFC PATCH v5 1/3] none-machine: allow cold plugging sysbus devices Damien Hedde
2022-05-24 13:48 ` [RFC PATCH v5 2/3] softmmu/memory: add memory_region_try_add_subregion function Damien Hedde
2022-05-24 13:48 ` [RFC PATCH v5 3/3] add sysbus-mmio-map qapi command Damien Hedde
2022-05-24 17:44 ` [RFC PATCH v5 0/3] Sysbus device generic QAPI plug support Mark Cave-Ayland
2022-05-25 9:51 ` Damien Hedde
2022-05-25 11:45 ` Peter Maydell
2022-05-25 13:32 ` Damien Hedde
2022-05-25 19:20 ` Mark Cave-Ayland
2022-05-30 9:50 ` Damien Hedde
2022-05-30 10:25 ` Peter Maydell
2022-05-30 14:05 ` Damien Hedde
2022-05-31 8:00 ` Mark Cave-Ayland
2022-05-31 9:22 ` Damien Hedde
2022-05-31 20:43 ` Mark Cave-Ayland
2022-06-01 8:39 ` Damien Hedde
2022-06-01 9:07 ` David Hildenbrand
2022-06-01 10:45 ` Mark Cave-Ayland
2022-06-01 10:36 ` Mark Cave-Ayland
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=20220524134809.40732-1-damien.hedde@greensocs.com \
--to=damien.hedde@greensocs.com \
--cc=alistair.francis@wdc.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.com \
/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).