qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).