[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v1 2/3] memory: Add sysbus memory device
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [PATCH v1 2/3] memory: Add sysbus memory device |
Date: |
Wed, 16 Apr 2014 17:09:40 +0200 |
On Wed, 16 Apr 2014 14:24:18 +0200
Alexander Graf <address@hidden> 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 <address@hidden>
>
> 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
>
>
- [Qemu-devel] [PATCH v1 1/3] qdev: Expose the qdev id string as a prop, (continued)
[Qemu-devel] [PATCH v1 2/3] memory: Add sysbus memory device, Peter Crosthwaite, 2014/04/14
[Qemu-devel] [PATCH v1 3/3] arm: xilinx_zynq: Use Sysbus Memory device for RAMs, Peter Crosthwaite, 2014/04/14