From: Igor Mammedov <imammedo@redhat.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: Ani Sinha <ani@anisinha.ca>,
edgari@xilinx.com, mark.burton@greensocs.com,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v4 13/14] hw/mem/system-memory: add a memory sysbus device
Date: Thu, 24 Feb 2022 10:55:21 +0100 [thread overview]
Message-ID: <20220224105521.1b760212@redhat.com> (raw)
In-Reply-To: <9d0cfe90-01bc-6008-664f-74bdaa9c145c@greensocs.com>
On Wed, 23 Feb 2022 11:19:49 +0100
Damien Hedde <damien.hedde@greensocs.com> wrote:
> On 2/23/22 10:44, Igor Mammedov wrote:
> > On Wed, 23 Feb 2022 10:07:05 +0100
> > Damien Hedde <damien.hedde@greensocs.com> wrote:
> >
> >> This device can be used to create a memory wrapped into a
> >> sysbus device.
> >> This device has one property 'readonly' which allows
> >> to choose between a ram or a rom.
> >>
> >
> >> The purpose for this device is to be used with qapi command
> >> device_add.
> > that's the way to add a device to QEMU but a don't actual
> > purpose described here, i.e. how board will use this
> > device/actual usecase and how it will be wired to board
> > and why it does have to be a sysbus device.
> >
> Sorry, this was unclear.
>
> It is a sysbus device in order to use it like any other sysbus device.
> The memory region it contains is exposed as a sysbus mmio.
aside of that sysbus is legacy fictional bus (albeit widely used),
it doesn't scale to non sysbus devices (me thinking about buss-less
pc-dimm & co) since eventually we would like to create mainstream
machine types via QMP as well.
> I can replace the commit message by the following paragraph:
>
> Boards instantiate memories by creating memory region objects which is
> not possible using QAPI commands.
That's not entirely true, you can use object-add with hostmem backends
which do provide a means to allocate memory_region.
(there is no rom hostmem backend probably (i.e. one that return rom memory region)
but that could be added).
Another benefit of approach is that one can replace backing
memory any other backend (file/memfd/pmem...) without affecting
device model.
> To create a memory, the user can instantiate and map this device by
> issuing the following commands:
> device_add driver=sysbus-memory size=0x1000 id=someram
> sysbus-mmio-map device=someram addr=0
I'd imagine more generic approach would look like:
object-add memory-backend-ram,id=mem1,size=0x1000,other_backend_twiks
device_add memdevice_frontend,memdev=mem1,addr=0x0
where [pre]plug hooks in machine can map device to
an appropriate address space/place at device realize time.
(see memory_device_[pre_]plug() for starters).
> >> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
> >> ---
> >> include/hw/mem/sysbus-memory.h | 28 ++++++++++++
> >> hw/mem/sysbus-memory.c | 80 ++++++++++++++++++++++++++++++++++
> >> hw/mem/meson.build | 2 +
> >> 3 files changed, 110 insertions(+)
> >> create mode 100644 include/hw/mem/sysbus-memory.h
> >> create mode 100644 hw/mem/sysbus-memory.c
> >>
> >> diff --git a/include/hw/mem/sysbus-memory.h b/include/hw/mem/sysbus-memory.h
> >> new file mode 100644
> >> index 0000000000..5c596f8b4f
> >> --- /dev/null
> >> +++ b/include/hw/mem/sysbus-memory.h
> >> @@ -0,0 +1,28 @@
> >> +/*
> >> + * SPDX-License-Identifier: GPL-2.0-or-later
> >> + *
> >> + * SysBusDevice Memory
> >> + *
> >> + * Copyright (c) 2021 Greensocs
> >> + */
> >> +
> >> +#ifndef HW_SYSBUS_MEMORY_H
> >> +#define HW_SYSBUS_MEMORY_H
> >> +
> >> +#include "hw/sysbus.h"
> >> +#include "qom/object.h"
> >> +
> >> +#define TYPE_SYSBUS_MEMORY "sysbus-memory"
> >> +OBJECT_DECLARE_SIMPLE_TYPE(SysBusMemoryState, SYSBUS_MEMORY)
> >> +
> >> +struct SysBusMemoryState {
> >> + /* <private> */
> >> + SysBusDevice parent_obj;
> >> + uint64_t size;
> >> + bool readonly;
> >> +
> >> + /* <public> */
> >> + MemoryRegion mem;
> >> +};
> >> +
> >> +#endif /* HW_SYSBUS_MEMORY_H */
> >> diff --git a/hw/mem/sysbus-memory.c b/hw/mem/sysbus-memory.c
> >> new file mode 100644
> >> index 0000000000..f1ad7ba7ec
> >> --- /dev/null
> >> +++ b/hw/mem/sysbus-memory.c
> >> @@ -0,0 +1,80 @@
> >> +/*
> >> + * SPDX-License-Identifier: GPL-2.0-or-later
> >> + *
> >> + * SysBusDevice Memory
> >> + *
> >> + * Copyright (c) 2021 Greensocs
> >> + */
> >> +
> >> +#include "qemu/osdep.h"
> >> +#include "hw/mem/sysbus-memory.h"
> >> +#include "hw/qdev-properties.h"
> >> +#include "qemu/log.h"
> >> +#include "qemu/module.h"
> >> +#include "qapi/error.h"
> >> +
> >> +static Property sysbus_memory_properties[] = {
> >> + DEFINE_PROP_UINT64("size", SysBusMemoryState, size, 0),
> >> + DEFINE_PROP_BOOL("readonly", SysBusMemoryState, readonly, false),
> >> + DEFINE_PROP_END_OF_LIST(),
> >> +};
> >> +
> >> +static void sysbus_memory_realize(DeviceState *dev, Error **errp)
> >> +{
> >> + SysBusMemoryState *s = SYSBUS_MEMORY(dev);
> >> + gchar *name;
> >> +
> >> + if (!s->size) {
> >> + error_setg(errp, "'size' must be non-zero.");
> >> + return;
> >> + }
> >> +
> >> + /*
> >> + * We impose having an id (which is unique) because we need to generate
> >> + * a unique name for the memory region.
> >> + * memory_region_init_ram/rom() will abort() (in qemu_ram_set_idstr()
> >> + * function if 2 system-memory devices are created with the same name
> >> + * for the memory region).
> >> + */
> >> + if (!dev->id) {
> >> + error_setg(errp, "system-memory device must have an id.");
> >> + return;
> >> + }
> >> + name = g_strdup_printf("%s.region", dev->id);
> >> +
> >> + if (s->readonly) {
> >> + memory_region_init_rom(&s->mem, OBJECT(dev), name, s->size, errp);
> >> + } else {
> >> + memory_region_init_ram(&s->mem, OBJECT(dev), name, s->size, errp);
> >> + }
> >> +
> >> + g_free(name);
> >> + if (*errp) {
> >> + return;
> >> + }
> >> +
> >> + sysbus_init_mmio(SYS_BUS_DEVICE(s), &s->mem);
> >> +}
> >> +
> >> +static void sysbus_memory_class_init(ObjectClass *klass, void *data)
> >> +{
> >> + DeviceClass *dc = DEVICE_CLASS(klass);
> >> +
> >> + dc->user_creatable = true;
> >> + dc->realize = sysbus_memory_realize;
> >> + device_class_set_props(dc, sysbus_memory_properties);
> >> +}
> >> +
> >> +static const TypeInfo sysbus_memory_info = {
> >> + .name = TYPE_SYSBUS_MEMORY,
> >> + .parent = TYPE_SYS_BUS_DEVICE,
> >> + .instance_size = sizeof(SysBusMemoryState),
> >> + .class_init = sysbus_memory_class_init,
> >> +};
> >> +
> >> +static void sysbus_memory_register_types(void)
> >> +{
> >> + type_register_static(&sysbus_memory_info);
> >> +}
> >> +
> >> +type_init(sysbus_memory_register_types)
> >> diff --git a/hw/mem/meson.build b/hw/mem/meson.build
> >> index 82f86d117e..04c74e12f2 100644
> >> --- a/hw/mem/meson.build
> >> +++ b/hw/mem/meson.build
> >> @@ -7,3 +7,5 @@ mem_ss.add(when: 'CONFIG_NVDIMM', if_true: files('nvdimm.c'))
> >> softmmu_ss.add_all(when: 'CONFIG_MEM_DEVICE', if_true: mem_ss)
> >>
> >> softmmu_ss.add(when: 'CONFIG_SPARSE_MEM', if_true: files('sparse-mem.c'))
> >> +
> >> +softmmu_ss.add(files('sysbus-memory.c'))
> >
>
next prev parent reply other threads:[~2022-02-24 9:58 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 9:06 [PATCH v4 00/14] Initial support for machine creation via QMP Damien Hedde
2022-02-23 9:06 ` [PATCH v4 01/14] machine: add phase_get() and document phase_check()/advance() Damien Hedde
2022-03-03 15:01 ` Philippe Mathieu-Daudé
2022-02-23 9:06 ` [PATCH v4 02/14] machine&vl: introduce phase_until() to handle phase transitions Damien Hedde
2022-03-18 13:29 ` Damien Hedde
2022-02-23 9:06 ` [PATCH v4 03/14] vl: support machine-initialized target in phase_until() Damien Hedde
2022-03-03 15:03 ` Philippe Mathieu-Daudé
2022-02-23 9:06 ` [PATCH v4 04/14] qapi/device_add: compute is_hotplug flag Damien Hedde
2022-03-03 15:04 ` Philippe Mathieu-Daudé
2022-02-23 9:06 ` [PATCH v4 05/14] qapi/device_add: handle the rom_order_override when cold-plugging Damien Hedde
2022-05-24 20:08 ` Jim Shu
2022-02-23 9:06 ` [PATCH v4 06/14] qapi/device_add: Allow execution in machine initialized phase Damien Hedde
2022-02-23 9:06 ` [PATCH v4 07/14] none-machine: add the NoneMachineState structure Damien Hedde
2022-03-03 14:36 ` Philippe Mathieu-Daudé
2022-05-24 20:09 ` Jim Shu
2022-02-23 9:07 ` [PATCH v4 08/14] none-machine: add 'ram-addr' property Damien Hedde
2022-03-03 14:41 ` Philippe Mathieu-Daudé
2022-03-03 16:19 ` Damien Hedde
2022-05-24 20:09 ` Jim Shu
2022-02-23 9:07 ` [PATCH v4 09/14] none-machine: allow cold plugging sysbus devices Damien Hedde
2022-03-03 14:44 ` Philippe Mathieu-Daudé
2022-05-24 20:09 ` Jim Shu
2022-02-23 9:07 ` [PATCH v4 10/14] none-machine: allow several cpus Damien Hedde
2022-02-23 9:07 ` [PATCH v4 11/14] softmmu/memory: add memory_region_try_add_subregion function Damien Hedde
2022-02-23 9:12 ` Damien Hedde
2022-03-03 13:32 ` Philippe Mathieu-Daudé
2022-03-04 10:53 ` Damien Hedde
2022-05-24 20:09 ` Jim Shu
2022-02-23 9:07 ` [PATCH v4 12/14] add sysbus-mmio-map qapi command Damien Hedde
2022-03-03 14:59 ` Philippe Mathieu-Daudé
2022-03-04 10:42 ` Damien Hedde
2022-05-24 20:09 ` Jim Shu
2022-02-23 9:07 ` [PATCH v4 13/14] hw/mem/system-memory: add a memory sysbus device Damien Hedde
2022-02-23 9:44 ` Igor Mammedov
2022-02-23 10:19 ` Damien Hedde
2022-02-24 9:55 ` Igor Mammedov [this message]
2022-02-24 11:43 ` Damien Hedde
2022-02-25 11:38 ` Igor Mammedov
2022-02-25 15:31 ` Damien Hedde
2022-03-03 15:16 ` Philippe Mathieu-Daudé
2022-05-24 20:10 ` Jim Shu
2022-02-23 9:07 ` [PATCH v4 14/14] hw: set user_creatable on opentitan/sifive_e devices Damien Hedde
2022-03-04 12:58 ` Philippe Mathieu-Daudé
2022-05-24 20:10 ` Jim Shu
2022-03-03 10:58 ` [PATCH v4 00/14] Initial support for machine creation via QMP Damien Hedde
2022-05-24 19:54 ` Jim Shu
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=20220224105521.1b760212@redhat.com \
--to=imammedo@redhat.com \
--cc=ani@anisinha.ca \
--cc=damien.hedde@greensocs.com \
--cc=edgari@xilinx.com \
--cc=mark.burton@greensocs.com \
--cc=mst@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).