qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: bharata@linux.vnet.ibm.com
Cc: qemu-devel@nongnu.org, david@gibson.dropbear.id.au,
	mdroth@linux.vnet.ibm.com, aik@au1.ibm.com, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH v2] spapr: Ensure all LMBs are represented in ibm, dynamic-memory
Date: Mon, 6 Jun 2016 11:02:04 -0500	[thread overview]
Message-ID: <57559E7C.20707@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160606144729.GC5343@in.ibm.com>

On 06/06/2016 09:47 AM, Bharata B Rao wrote:
> On Mon, Jun 06, 2016 at 09:14:48AM -0500, Nathan Fontenot wrote:
>> On 06/06/2016 06:37 AM, 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-usb-xhci. DDW depends
>>> on maximum addressable memory returned 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,dynamic-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.
>>>
>>> To work around this guest kernel bug, ensure that ibm,dynamic-memory
>>> has information about all the LMBs (RMA, boot-time LMBs, future
>>> hotpluggable LMBs, and dummy LMBs to cover the gap between RAM and
>>> hotpluggable region).
>>>
>>> RMA is represented separately by memory@0 node. Hence mark RMA LMBs
>>> and also the LMBs for the gap b/n RAM and hotpluggable region as
>>> reserved so that these LMBs are not recounted/counted by guest.
>>
>> What does qemu do if a guest tries to add or remove a reserved LMB?
> 
> Currently in this approach, LMBs belonging two regions are marked as
> reserved:
> 
> - RMA region
> - Gap b/n end of RAM and beginning of hotplug region
> 
> Any hotplug attempts to above regions will be refused by QEMU as they
> don't fall under the hotplug memory region.

That's good. I wanted to make sure that this wouldn't break anything
with the current memory hotplug code paths.

> 
>>
>> Asking because the current guest code (drmgr and kernel) does not
>> take the reserved flag into consideration when searching for lmbs to
>> add/remove. This seems like something I should be fixed on the guest
>> side.
> 
> Oh ok, but as I said earlier QEMU won't send hotplug request for such
> LMBs.

Yes, but that doesn't stop a user from running the drmgr command and
making a request.

> 
> However, I am seeing that when I mark RMA LMBs as reserved in
> ibm,dynamic-memory and create separate memory@0 to represent RMA, guest is
> just ignoring those LMBs and not doing double detection of RMA memory.
> 
> Same is true for the reserved LMBs that I put in ibm,dyanamic-memory
> to cover the gap b/n RAM and hotplug region. Guest isn't not
> considering this.
> 
> Do you still see any problems ?

This should be fine. The boot-up code ignores any LMB that has the
'reserved' flag set.

-Nathan

> 
> Regards,
> Bharata.
> 

  reply	other threads:[~2016-06-06 16:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 11:37 [Qemu-devel] [RFC PATCH v2] spapr: Ensure all LMBs are represented in ibm, dynamic-memory Bharata B Rao
2016-06-06 14:14 ` Nathan Fontenot
2016-06-06 14:47   ` Bharata B Rao
2016-06-06 16:02     ` Nathan Fontenot [this message]
2016-06-07  0:46 ` Michael Roth
2016-06-07  2:16   ` David Gibson

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=57559E7C.20707@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=aik@au1.ibm.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=mdroth@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).