qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug
Date: Mon, 23 Apr 2012 16:31:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/22/2012 05:20 PM, Gleb Natapov wrote:
> On Sun, Apr 22, 2012 at 05:13:27PM +0300, Avi Kivity wrote:
> > On 04/22/2012 05:09 PM, Gleb Natapov wrote:
> > > On Sun, Apr 22, 2012 at 05:06:43PM +0300, Avi Kivity wrote:
> > > > On 04/22/2012 04:56 PM, Gleb Natapov wrote:
> > > > > start. We will need it for migration anyway.
> > > > >
> > > > > > hotplug-able memory slots i.e. initial system memory is not modeled 
> > > > > > with
> > > > > > memslots. The concept could be generalized to include all memory 
> > > > > > though, or it
> > > > > > could more closely follow kvm-memory slots.
> > > > > OK, I hope final version will allow for memory < 4G to be 
> > > > > hot-pluggable.
> > > > 
> > > > Why is that important?
> > > > 
> > > Because my feeling is that people that want to use this kind of feature
> > > what to start using it with VMs smaller than 4G. Of course not all
> > > memory have to be hot unpluggable. Making first 1M or event first 128M not
> > > unpluggable make perfect sense.
> > 
> > Can't you achieve this with -m 1G, -device dimm,size=1G,populated=true
> > -device dimm,size=1G,populated=false?
> > 
> From this:
>
> (for hw/pc.c PCI hole is currently [below_4g_mem_size, 4G), so
> hotplugged memory should start from max(4G, above_4g_mem_size).
>
> I understand that hotpluggable memory can start from above 4G only. With
> the config above we will have memory hole from 1G to PCI memory hole.
> May be not a big problem, but I do not see technical reason for the constrain.
>  
> > (I don't think hotplugging below 512MB is needed, but I don't have any
> > real data on this).
> > 
> 512MB looks like a reasonable limitation too, but again if there is not
> technical reason for having the limitation why have it?
>

I was thinking about not having tons of 128MB slots, so we don't have a
configuration that is far from reality.  But maybe this thinking is too
conservative.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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