| Message ID | a944bc1db88e857e9f1440dce228f76e41624f6a.1397527916.git.peter.crosthwaite@xilinx.com |
|---|---|
| State | New |
| Headers | show |
On 15.04.14 04:21, Peter Crosthwaite wrote: > Add a sysbus device consisting of a single ram. This allows for > instantiation of RAM just like any other device. There are a number > of good reasons to want to do this this: > > 1: Consistency. RAM is not that special where board level files should > have to instantiate it with a completely different API. This reduces > complexity of board level development by hiding the memory API > completely and handling everything via the sysbus API. > > 2: Device tree completeness. Ram Now shows up in info-qtree and > friends. E.g. Info qtree gives meaningful information under the > root system bus: > > dev: sysbus-memory, id "zynq.ocm_ram" > size = 262144 (0x40000) > read-only = false > irq 0 > mmio 00000000fffc0000/0000000000040000 > dev: sysbus-memory, id "zynq.ext_ram" > size = 134217728 (0x8000000) > read-only = false > irq 0 > mmio 0000000000000000/0000000008000000 > > 3: Remove dependence of global state. Board files don't have to > explicity request the global singleton (and much unloved) > address_space_memory() and go hacking on it. address_space_memory() > is still ultimately used, but the ugliness is hidden in one place - the > sysbus core (we can fix that another day). > > 4: Data driven machine creation. There is list discussion on being able > to create or append-to sysbus machines in a data-driven way (whether > thats from command-line, monitor or scripts or whatever). This patch > removes the memory special case from that problem and allows RAM > instantiation to come via whatever solutions we come up with sysbus > device instantiation. > > Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Could you please show that this approach works for more complicated machines, like x86's pc machine and its PCI holes? Alex
On Wed, 16 Apr 2014 14:24:18 +0200 Alexander Graf <agraf@suse.de> wrote: > > On 15.04.14 04:21, Peter Crosthwaite wrote: > > Add a sysbus device consisting of a single ram. This allows for > > instantiation of RAM just like any other device. There are a number > > of good reasons to want to do this this: > > > > 1: Consistency. RAM is not that special where board level files should > > have to instantiate it with a completely different API. This reduces > > complexity of board level development by hiding the memory API > > completely and handling everything via the sysbus API. > > > > 2: Device tree completeness. Ram Now shows up in info-qtree and > > friends. E.g. Info qtree gives meaningful information under the > > root system bus: > > > > dev: sysbus-memory, id "zynq.ocm_ram" > > size = 262144 (0x40000) > > read-only = false > > irq 0 > > mmio 00000000fffc0000/0000000000040000 > > dev: sysbus-memory, id "zynq.ext_ram" > > size = 134217728 (0x8000000) > > read-only = false > > irq 0 > > mmio 0000000000000000/0000000008000000 > > > > 3: Remove dependence of global state. Board files don't have to > > explicity request the global singleton (and much unloved) > > address_space_memory() and go hacking on it. address_space_memory() > > is still ultimately used, but the ugliness is hidden in one place - the > > sysbus core (we can fix that another day). > > > > 4: Data driven machine creation. There is list discussion on being able > > to create or append-to sysbus machines in a data-driven way (whether > > thats from command-line, monitor or scripts or whatever). This patch > > removes the memory special case from that problem and allows RAM > > instantiation to come via whatever solutions we come up with sysbus > > device instantiation. > > > > Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> > > Could you please show that this approach works for more complicated > machines, like x86's pc machine and its PCI holes? I'm planning to use bussless DIMM devices for re-factoring initial memory on x86 pc machine once its code stabilized. It of cause doesn't hide memory_* API like sysbus does but would allow much more finer control, like select proper backend (ram/tph/whatever/host numa policies) and specify guest properties like GPA, and numa node proximity. Maybe it could be used here instead of sysbus device. > > > Alex > >
Peter, Am 15.04.2014 04:21, schrieb Peter Crosthwaite: > Add a sysbus device consisting of a single ram. This allows for > instantiation of RAM just like any other device. There are a number > of good reasons to want to do this this: > > 1: Consistency. RAM is not that special where board level files should > have to instantiate it with a completely different API. This reduces > complexity of board level development by hiding the memory API > completely and handling everything via the sysbus API. > > 2: Device tree completeness. Ram Now shows up in info-qtree and > friends. E.g. Info qtree gives meaningful information under the > root system bus: > > dev: sysbus-memory, id "zynq.ocm_ram" > size = 262144 (0x40000) > read-only = false > irq 0 > mmio 00000000fffc0000/0000000000040000 > dev: sysbus-memory, id "zynq.ext_ram" > size = 134217728 (0x8000000) > read-only = false > irq 0 > mmio 0000000000000000/0000000008000000 I had warned that I would nack any patch that justifies changes with "info qtree", so here's your gentle NAK. Please help deciding on the following patches, which do show such devices the QOM way: http://patchwork.ozlabs.org/patch/317224/ http://patchwork.ozlabs.org/patch/343136/ http://patchwork.ozlabs.org/patch/347064/ Note that this doesn't mean we can't create new SysBusDevices, it means the commit message should be changed. Regards, Andreas > > 3: Remove dependence of global state. Board files don't have to > explicity request the global singleton (and much unloved) > address_space_memory() and go hacking on it. address_space_memory() > is still ultimately used, but the ugliness is hidden in one place - the > sysbus core (we can fix that another day). > > 4: Data driven machine creation. There is list discussion on being able > to create or append-to sysbus machines in a data-driven way (whether > thats from command-line, monitor or scripts or whatever). This patch > removes the memory special case from that problem and allows RAM > instantiation to come via whatever solutions we come up with sysbus > device instantiation. > > Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> > --- > > hw/core/Makefile.objs | 1 + > hw/core/sysbus-memory.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 64 insertions(+) > create mode 100644 hw/core/sysbus-memory.c
On Fri, May 16, 2014 at 3:22 PM, Andreas Färber <afaerber@suse.de> wrote: > Peter, > > Am 15.04.2014 04:21, schrieb Peter Crosthwaite: >> Add a sysbus device consisting of a single ram. This allows for >> instantiation of RAM just like any other device. There are a number >> of good reasons to want to do this this: >> >> 1: Consistency. RAM is not that special where board level files should >> have to instantiate it with a completely different API. This reduces >> complexity of board level development by hiding the memory API >> completely and handling everything via the sysbus API. >> >> 2: Device tree completeness. Ram Now shows up in info-qtree and >> friends. E.g. Info qtree gives meaningful information under the >> root system bus: >> >> dev: sysbus-memory, id "zynq.ocm_ram" >> size = 262144 (0x40000) >> read-only = false >> irq 0 >> mmio 00000000fffc0000/0000000000040000 >> dev: sysbus-memory, id "zynq.ext_ram" >> size = 134217728 (0x8000000) >> read-only = false >> irq 0 >> mmio 0000000000000000/0000000008000000 > > I had warned that I would nack any patch that justifies changes with > "info qtree", so here's your gentle NAK. > > Please help deciding on the following patches, which do show such > devices the QOM way: > So I'm shelving this for the interim anyway. My latests series may infact obsolete this with full MR qomifcation. You could prehaps just setup TYPE_MEMORY_REGION_RAM (.parent = TYPE_MEMORY_REGION). Then object-new and friends can be used to achieve the same set of goals as stated in this commit message (except #3). > http://patchwork.ozlabs.org/patch/317224/ > http://patchwork.ozlabs.org/patch/343136/ > http://patchwork.ozlabs.org/patch/347064/ > Yep, this latest one is already on my "to-review" list. Regards, Peter > Note that this doesn't mean we can't create new SysBusDevices, it means > the commit message should be changed. > > Regards, > Andreas > >> >> 3: Remove dependence of global state. Board files don't have to >> explicity request the global singleton (and much unloved) >> address_space_memory() and go hacking on it. address_space_memory() >> is still ultimately used, but the ugliness is hidden in one place - the >> sysbus core (we can fix that another day). >> >> 4: Data driven machine creation. There is list discussion on being able >> to create or append-to sysbus machines in a data-driven way (whether >> thats from command-line, monitor or scripts or whatever). This patch >> removes the memory special case from that problem and allows RAM >> instantiation to come via whatever solutions we come up with sysbus >> device instantiation. >> >> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> >> --- >> >> hw/core/Makefile.objs | 1 + >> hw/core/sysbus-memory.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 64 insertions(+) >> create mode 100644 hw/core/sysbus-memory.c > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
On Wed, Apr 16, 2014 at 10:24 PM, Alexander Graf <agraf@suse.de> wrote: > > On 15.04.14 04:21, Peter Crosthwaite wrote: >> >> Add a sysbus device consisting of a single ram. This allows for >> instantiation of RAM just like any other device. There are a number >> of good reasons to want to do this this: >> >> 1: Consistency. RAM is not that special where board level files should >> have to instantiate it with a completely different API. This reduces >> complexity of board level development by hiding the memory API >> completely and handling everything via the sysbus API. >> >> 2: Device tree completeness. Ram Now shows up in info-qtree and >> friends. E.g. Info qtree gives meaningful information under the >> root system bus: >> >> dev: sysbus-memory, id "zynq.ocm_ram" >> size = 262144 (0x40000) >> read-only = false >> irq 0 >> mmio 00000000fffc0000/0000000000040000 >> dev: sysbus-memory, id "zynq.ext_ram" >> size = 134217728 (0x8000000) >> read-only = false >> irq 0 >> mmio 0000000000000000/0000000008000000 >> >> 3: Remove dependence of global state. Board files don't have to >> explicity request the global singleton (and much unloved) >> address_space_memory() and go hacking on it. address_space_memory() >> is still ultimately used, but the ugliness is hidden in one place - the >> sysbus core (we can fix that another day). >> >> 4: Data driven machine creation. There is list discussion on being able >> to create or append-to sysbus machines in a data-driven way (whether >> thats from command-line, monitor or scripts or whatever). This patch >> removes the memory special case from that problem and allows RAM >> instantiation to come via whatever solutions we come up with sysbus >> device instantiation. >> >> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> > > > Could you please show that this approach works for more complicated > machines, like x86's pc machine and its PCI holes? > Hi Alex, Do you mean attaching it within a PCI address space? Im not sure that's valid. That would require some sort of generalisation that applied to both sysbus and PCI. I actually had a go at something like this a while back. Basically, the setup was for PCI devices to inherit from sysbus. This allowed solving the reverse problem. Attaching a PCI device to sysbus. I guess with a few changes it could be made to work both ways, but it seems the sysbus and PC world are completely separate the way the tree stands today. Regards, Peter > > Alex > >
diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs index 5377d05..4a99840 100644 --- a/hw/core/Makefile.objs +++ b/hw/core/Makefile.objs @@ -9,6 +9,7 @@ common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o common-obj-$(CONFIG_XILINX_AXI) += stream.o common-obj-$(CONFIG_PTIMER) += ptimer.o common-obj-$(CONFIG_SOFTMMU) += sysbus.o +common-obj-$(CONFIG_SOFTMMU) += sysbus-memory.o common-obj-$(CONFIG_SOFTMMU) += machine.o common-obj-$(CONFIG_SOFTMMU) += null-machine.o common-obj-$(CONFIG_SOFTMMU) += loader.o diff --git a/hw/core/sysbus-memory.c b/hw/core/sysbus-memory.c new file mode 100644 index 0000000..6361feb --- /dev/null +++ b/hw/core/sysbus-memory.c @@ -0,0 +1,63 @@ +/* + * Sysbus Attached Memory. + * + * Copyright (c) 2014 Xilinx Inc. + * Written by Peter Crosthwaite <peter.crosthwaite@xilinx.com> + * + * This code is licensed under the GPL. + */ + +#include "hw/sysbus.h" + +#define TYPE_SYS_BUS_MEMORY "sysbus-memory" + +#define SYS_BUS_MEMORY(obj) \ + OBJECT_CHECK(SysBusMemory, (obj), TYPE_SYS_BUS_MEMORY) + +typedef struct SysBusMemory { + SysBusDevice parent_obj; + + uint64_t size; + bool read_only; + + MemoryRegion mem; +} SysBusMemory; + +static void sysbus_memory_realize(DeviceState *dev, Error **errp) +{ + SysBusMemory *s = SYS_BUS_MEMORY(dev); + + memory_region_init_ram(&s->mem, OBJECT(dev), + dev->id ? dev->id : "sysbus-memory", s->size); + memory_region_set_readonly(&s->mem, s->read_only); + vmstate_register_ram_global(&s->mem); + sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->mem); +} + +static Property sysbus_memory_props[] = { + DEFINE_PROP_UINT64("size", SysBusMemory, size, 0), + DEFINE_PROP_BOOL("read-only", SysBusMemory, read_only, false), + DEFINE_PROP_END_OF_LIST(), +}; + +static void sysbus_memory_class_init(ObjectClass *oc, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(oc); + + dc->props = sysbus_memory_props; + dc->realize = sysbus_memory_realize; +} + +static const TypeInfo sysbus_memory_info = { + .name = TYPE_SYS_BUS_MEMORY, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(SysBusMemory), + .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)
Add a sysbus device consisting of a single ram. This allows for instantiation of RAM just like any other device. There are a number of good reasons to want to do this this: 1: Consistency. RAM is not that special where board level files should have to instantiate it with a completely different API. This reduces complexity of board level development by hiding the memory API completely and handling everything via the sysbus API. 2: Device tree completeness. Ram Now shows up in info-qtree and friends. E.g. Info qtree gives meaningful information under the root system bus: dev: sysbus-memory, id "zynq.ocm_ram" size = 262144 (0x40000) read-only = false irq 0 mmio 00000000fffc0000/0000000000040000 dev: sysbus-memory, id "zynq.ext_ram" size = 134217728 (0x8000000) read-only = false irq 0 mmio 0000000000000000/0000000008000000 3: Remove dependence of global state. Board files don't have to explicity request the global singleton (and much unloved) address_space_memory() and go hacking on it. address_space_memory() is still ultimately used, but the ugliness is hidden in one place - the sysbus core (we can fix that another day). 4: Data driven machine creation. There is list discussion on being able to create or append-to sysbus machines in a data-driven way (whether thats from command-line, monitor or scripts or whatever). This patch removes the memory special case from that problem and allows RAM instantiation to come via whatever solutions we come up with sysbus device instantiation. Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> --- hw/core/Makefile.objs | 1 + hw/core/sysbus-memory.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+) create mode 100644 hw/core/sysbus-memory.c