[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v0 for 2.7] spapr: Work around the memory ho
Bharata B Rao
Re: [Qemu-devel] [RFC PATCH v0 for 2.7] spapr: Work around the memory hotplug failure with DDW
Tue, 26 Apr 2016 11:00:06 +0530
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.
> >address@hidden 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
> >Before this change, the guest would have
> >Scenario 1
> >address@hidden for RMA
> >address@hidden for rest of the boot time memory
> >ibm,dynamic-reconfiguration-memory for hot-pluggable memory.
> >After this commit, the guest will have
> >Scenario 2
> >address@hidden 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.