qemu-devel
[Top][All Lists]
Advanced

[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
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]