Re: [SeaBIOS] [PATCH] memory hotplug

[Igor Mammedov]

On 03/16/2012 03:09 PM, Vasilis Liaskovitis wrote:
> Hi,
>
> On Thu, Mar 15, 2012 at 02:01:38PM +0200, Gleb Natapov wrote:
> > Commenting a little bit late, but since you've said that you are working on
> > a new version of the patch... better late than never.
> >
> > On Thu, Aug 11, 2011 at 04:39:38PM +0200, Vasilis Liaskovitis wrote:
> > > Hi,
> > >
> > > I am testing a set of experimental patches for memory-hotplug on x86_64 host /
> > > guest combinations. I have implemented this in a similar way to cpu-hotplug.
> > >
> > > A dynamic SSDT table with all memory devices is created at boot time.  This
> > > table calls static methods from the DSDT.  A byte array indicates which memory
> > > device is online or not. This array is kept in sync with a qemu-kvm bitmap array
> > > through ioport 0xaf20. Qemu-kvm updates this table on a "mem_set" command and
> > > an ACPI event is triggered.
> > >
> > > Memory devices are 128MB in size (to match /sys/devices/memory/block_size_bytes
> > > in x86_64). They are constructed dynamically in src/ssdt-mem.asl , similarly to
> > > hotpluggable-CPUs.  The _CRS memstart-memend attribute for each memory device is
> > > defined accordingly, skipping the hole at 0xe0000000 - 0x100000000.
> > > Hotpluggable memory is always located above 4GB.
> >
> > What is the reason for this limitation?
>
> We currently model a PCI hole from below_4g_mem_size to 4GB, see i440fx_init
> call in pc_init1. The decision was discussed here:
> http://patchwork.ozlabs.org/patch/105892/
> afaict because there was no clear resolution on using a top-of-memory register.
> So, hotplugging will start at 4GB + above_4g_mem_size. Unless we can model the
> pci hole more accurately hardware-wise.
> > > Qemu-kvm sets the upper bound of hotpluggable memory with "maxmem = [totalmemory in
> > > MB]" on the command line. Maxmem is an argument for "-m" similar to maxcpus for smp.
> > > E.g. "-m 1024,maxmem=2048" on the qemu command line will create memory devices
> > > for 2GB of RAM, enabling only 1GB initially.
> > >
> > > Qemu_monitor triggers a memory hotplug with:
> > > (qemu) mem_set [memory range in MBs] online
> >
> > As far as I see mem_set does not get memory range as a parameter. The
> > parameter is amount of memory to add/remove and memory is added/removed
> > to/from the top.
> >
> > This is not flexible enough.  Find grained control for memory slots is
> > needed. What about exposing memory slot configuration to command line
> > like this:
> >
> > -memslot mem=size,populated=yes|no
> >
> > adding one of those for each slot.
>
> yes, I agree we need this.
> Is the idea to model all physical DIMMs? For initial system RAM does it make
> sense to explicitly specify slots at the command line, or infer them?
>
> I think we can allocate a new qemu ram MemoryRegion for each new hotplugged
> slot/DIMM, so there will be a 1-1 mapping between new populated slots and
> qemu memory ram regions.  Perhaps we want initial memory allocation to also
> comply with physical slot/DIMM modeling. Initial (cold) RAM is created as
> a single MemoryRegion pc.ram
>
> Also in kvm we can easily run out of kvm_memory_slots (10 slots per VM and 32
> system-wide I think)
> > mem_set will get slot id to populate/depopulate just like cpu_set gets
> > cpu slot number to remove and not just yanks cpus with highest slot id.
>
> right, but I think for upstream qemu, people would like to eventually use device_add,
> instead of a new mem_set command. Pretty much the same way as cpu hotplug?
>
> For this to happen, memory devices should be modeled in QOM/qdev. Are we planning
> on keeping a CPUSocket structures for CPUs? or perhaps modelling a memory controller

I'd rather dump CPUSocket structure unless it's really required, it was introduced just
for providing hotplug-able icc bus for cpus since hot-plug on sysbus was disabled.
> is the right way. What type should the memory controller/devices be a child of?
>
> I 'll try to resubmit in a few weeks time, though depending on feedack qom/qdev of
> memory devices will probably take longer.
>
> thanks,
> Vasilis