All of lore.kernel.org
 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 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.