Re: [Qemu-devel] [PATCH v5 05/14] vl: handle "-device dimm"

[Hu Tao <hutao@cn.fujitsu.com>]

On Tue, Jul 09, 2013 at 06:53:47PM +0200, Igor Mammedov wrote:
> On Thu, 27 Jun 2013 08:55:25 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > Il 27/06/2013 07:08, Wanlong Gao ha scritto:
> > > Do we really need to specify the memory range? I suspect that we can
> > > follow current design of normal memory in hot-plug memory.
> > 
> > I think we can do both.  I'm afraid that the configuration of the VM
> > will not be perfectly reproducible without specifying the range, more so
> > if you allow hotplug.
> > 
> > > Currently,
> > > we just specify the size of normal memory in each node, and the range
> > > in normal memory is node by node. Then I think we can just specify
> > > the memory size of hot-plug in each node, then the hot-plug memory
> > > range is also node by node, and the whole hot-plug memory block is
> > > just located after the normal memory block. If so, the option can
> > > come like:
> > >     -numa node,nodeid=0,mem=2G,cpus=0-1,mem-hotplug=2G,mem-policy=membind,mem-hostnode=0-1,mem-hotplug-policy=interleave,mem-hotplug-hostnode=1
> > >     -numa node,nodeid=1,mem=2G,cpus=2-3,mem-hotplug=2G,mem-policy=preferred,mem-hostnode=1,mem-hotplug-policy=membind,mem-hotplug-hostnode=0-1
> > 
> > I think specifying different policies and bindings for normal and
> > hotplug memory is too much fine-grained.  If you really want that, then
> > you would need something like
> > 
> >     -numa node,nodeid=0,cpus=0-1 \
> >     -numa mem,nodeid=0,size=2G,policy=membind,hostnode=0-1 \
> >     -numa mem,nodeid=0,size=2G,policy=interleave,hostnode=1,populated=no
> > 
> > Hmm... this actually doesn't look too bad, and it is much more
> > future-proof.  Eduardo, what do you think about it?  Should Wanlong redo
> > his patches to support this "-numa mem" syntax?  Parsing it should be
> > easy using the QemuOpts visitor, too.
> 
> Is hot-plugged memory and its bindings to numa nodes have to be specified
> at startup?
> 
> How about extending -m option to support following syntax:
> 
>   -m initial_mem[, number_of_hotplug_dimms, max_mem]]
> 
> and dynamically forming MEMXX._CRS/_PXM resources on demand instead
> of creating static resources in SSDT.
> 
> without necessity to specify to be hot-plugged DIMMs at startup, hot-plug
> could become more flexible since arbitrarily sized DIMMs with required NUMA
> mapping could be specified during hot-plug time, for example:
> 
>   device_add dimm,id=dimm1,bus=membus.0,size=3G,node=1,...

Seems impossible as ACPI memory devices' ranges must be specified at startup,
but I'll be glad if I'm wrong.

> 
> the only limit would be left is a number of increments(DIMM slots), due to
> need to pre-generate ACPI memory devices that could supply _CRS/_PXM
> resources later.
> 
> 
> > Paolo
> > 
> > 
>