From: Gleb Natapov <gleb@redhat.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: kvm@vger.kernel.org, seabios@seabios.org
Subject: Re: [PATCH][SeaBIOS] memory hotplug
Date: Thu, 15 Mar 2012 14:01:38 +0200 [thread overview]
Message-ID: <20120315120138.GA22368@redhat.com> (raw)
In-Reply-To: <20110811143938.GA15036@dhcp-192-168-178-175.profitbricks.localdomain>
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?
> 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.
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.
--
Gleb.
next prev parent reply other threads:[~2012-03-15 12:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 14:39 [PATCH][SeaBIOS] memory hotplug Vasilis Liaskovitis
2011-08-29 9:24 ` Lai Jiangshan
2011-09-06 8:07 ` Vasilis Liaskovitis
[not found] ` <4E674059.9070307@cn.fujitsu.com>
2011-09-08 16:21 ` [PATCH] " Vasilis Liaskovitis
2012-03-15 12:01 ` Gleb Natapov [this message]
2012-03-16 14:09 ` [PATCH][SeaBIOS] " Vasilis Liaskovitis
2012-03-16 14:31 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120315120138.GA22368@redhat.com \
--to=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=seabios@seabios.org \
--cc=vasilis.liaskovitis@profitbricks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox