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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 16/07/2013 12:19, Igor Mammedov ha scritto:
> On Tue, 16 Jul 2013 08:19:48 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> Il 16/07/2013 03:27, Hu Tao ha scritto:
>>>> I think it's the same.  One "-numa mem" option = one "-device dimm"
>>>> option; both define one range.  Unused memory ranges may remain if you
>>>> stumble upon a unusable range such as the PCI window.  For example two
>>>> "-numa mem,size=2G" options would allocate memory from 0 to 2G and from
>>>> 4 to 6G.
>>>
>>> So we can drop -dimm if we agree on -numa mem?
>>
>> Yes, the point of the "-numa mem" proposal was to avoid the concept of a
>> "partially initialized device" that you had for DIMMs.
> I've though -numa mem was for mapping initial memory to numa nodes.
> It seem wrong to use it for representing dimm device and also limiting
> possible hotplugged regions to specified at startup ranges.

It's not for DIMM devices, it is for reserving areas of the address
space for hot-plugged RAM.  DIMM hotplug is done with "device_add dimm"
(and you can also use "-numa mem,populated=no,... -device dimm,..." to
start a VM with hot-unpluggable memory).

> we can leave -numa for initial memory mapping and manage of the mapping
> of hotpluggable regions with -device dimm,node=X,size=Y.
> 
> It that case command line -device dimm will provide a fully initialized
> dimm device usable at startup (but hot-unplugable) and
>   (monitor) device_add dimm,,node=X,size=Y
> would serve hot-plug case.
> 
> That way arbitrary sized dimm could be hot-pluged without specifying them
> at startup, like it's done on bare-metal.

But the memory ranges need to be specified at startup in the ACPI
tables, and that's what "-numa mem" is for.

> In addition command line -device would be used in migration case to describe
> already hot-plugged dimms on target.

Yep.

Paolo