From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-devel@nongnu.org, aik@au1.ibm.com,
Michael Roth <mdroth@linux.vnet.ibm.com>,
qemu-ppc@nongnu.org, Nathan Fontenot <nfont@linux.vnet.ibm.com>,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0 for 2.7] spapr: Work around the memory hotplug failure with DDW
Date: Tue, 26 Apr 2016 11:00:06 +0530 [thread overview]
Message-ID: <20160426053006.GA10063@in.ibm.com> (raw)
In-Reply-To: <571EDD1F.3090805@ozlabs.ru>
On Tue, Apr 26, 2016 at 01:14:39PM +1000, Alexey Kardashevskiy wrote:
> On 04/19/2016 09:51 PM, Bharata B Rao wrote:
> >Memory hotplug can fail for some combinations of RAM and maxmem when
> >DDW is enabled in the presence of devices like nec-xhci-usb. DDW depends
> >on maximum addressable memory by guest and this value is currently
> >being calculated wrongly by the guest kernel routine memory_hotplug_max().
> >While there is an attempt to fix the guest kernel(*), this patch works
> >around the problem within QEMU itself.
> >
> >memory_hotplug_max() routine in the guest kernel arrives at max
> >addressable memory by multiplying lmb-size with the lmb-count obtained
> >from ibm,dyanmic-memory property. There are two assumptions here:
> >
> >- All LMBs are part of ibm,dynamic memory: This is not true for PowerKVM
> > where only hot-pluggable LMBs are present in this property.
> >- The memory area comprising of RAM and hotplug region is contiguous: This
> > needn't be true always for PowerKVM as there can be gap between
> > boot time RAM and hotplug region.
> >
> >This work around involves having all the LMBs (RMA, rest of the boot time
> >LMBs and hot-pluggable LMBs) as part of ibm,dynamic-memory so that
> >guest kernel's calculation of max addressable memory comes out correct
> >resulting in correct DDW value which prevents memory hotplug failures.
> >memory@0 is created for RMA, but RMA LMBs are also represented as
> >"reserved" LMBs in ibm,dynamic-memory. Parts of this are essenitally a
> >revert of e8f986fc57a664a74b9f685b466506366a15201b.
> >
> >In addition to this, the alignment of hotplug memory region is reduced from
> >current 1G to 256M (LMB size in PowerKVM) so that we don't end up with any
> >gaps between boot time RAM and hotplug region.
> >
> >This change has a side effect on how the memory nodes in DT are
> >represented before and after this change. As an example consider
> >a guest with the following memory related command line options:
> >
> >-m 4G,slots=32,maxmem=8G -numa node,nodeid=0,mem=2G -numa node,nodeid=1,mem=2G
> >
> >Before this change, the guest would have
> >
> >Scenario 1
> >----------
> >memory@0 for RMA
> >memory@80000000 for rest of the boot time memory
> >ibm,dynamic-reconfiguration-memory for hot-pluggable memory.
> >
> >After this commit, the guest will have
> >
> >Scenario 2
> >----------
> >memory@0 for RMA
> >ibm,dynamic-reconfiguration-memory for the entire memory including
> >RMA, boot time memory as well as hot-pluggable memory.
> >
> >If an existing guest having DT nodes as in Scenario 1 above is migrated
> >to a QEMU which has this change, at the target, it continues to have the
> >DT nodes as in Scenario 1. However after 1st reboot, the DT representation
> >changes over to Scenario 2.
>
>
> Does this patch also enable hot-unplug or RMA and boot time LMBs?
No, this patch will not enable hot-unplug for RMA or boot time LMBs.
>
> Also, this would look nicer on top of "[RFC for-2.7 00/11] A new
> infrastructure for guest device trees" where all memory DT nodes are in one
> place so it is easier to follow what exactly you...
Let me take a look at that patchset.
Regards,
Bharata.
next prev parent reply other threads:[~2016-04-26 5:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 11:51 [Qemu-devel] [RFC PATCH v0 for 2.7] spapr: Work around the memory hotplug failure with DDW Bharata B Rao
2016-04-26 3:14 ` Alexey Kardashevskiy
2016-04-26 5:30 ` Bharata B Rao [this message]
2016-05-03 23:30 ` Michael Roth
2016-05-04 2:38 ` Bharata B Rao
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=20160426053006.GA10063@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=aik@au1.ibm.com \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=mdroth@linux.vnet.ibm.com \
--cc=nfont@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.