[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug |
Date: |
Tue, 26 Mar 2013 11:20:59 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Mar 20, 2013 at 02:18:00PM +0800, li guang wrote:
> 在 2013-01-09三的 01:08 +0100,Andreas Färber写道:
> > Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis:
> > > Because dimm layout needs to be configured on machine-boot, all dimm
> > > devices
> > > need to be specified on startup command line (either with populated=on or
> > > with
> > > populated=off). The dimm information is stored in dimm configuration
> > > structures.
> > >
> > > After machine startup, dimms are hot-added or removed with normal
> > > device_add
> > > and device_del operations e.g.:
> > > Hot-add syntax: "device_add dimm,id=mydimm0,bus=membus.0"
> > > Hot-remove syntax: "device_del dimm,id=mydimm0"
> >
> > This sounds contradictory: Either all devices need to be specified on
> > the command line, or they can be hot-added via monitor.
> >
> > Assuming a fixed layout at startup, I wonder if there is another clever
> > way to model this... For CPU hotplug Anthony had suggested to have a
> > fixed set of link<Socket> properties that get set to a CPU socket as
> > needed. Might a similar strategy work for memory, i.e. a
> > startup-configured amount of link<DIMM>s on /machine/dimm[n] that point
> > to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then
> > simply work via QMP qom-set command. (CC'ing some people)
>
>
> Sorry, what's link<>, did it adopted by cpu-QOM?
"link<...>" is a QOM construct, allowing properties that point to other
objects. We don't use it on the CPU objects yet.
> can you give some hints?
Look for mentions of "link" in the doc comments at include/qom/object.h.
--
Eduardo