From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWPNZ-0008AU-8X for qemu-devel@nongnu.org; Tue, 23 Sep 2014 08:39:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWPNN-00015t-SC for qemu-devel@nongnu.org; Tue, 23 Sep 2014 08:39:37 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:40893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWPNN-00012z-0P for qemu-devel@nongnu.org; Tue, 23 Sep 2014 08:39:25 -0400 Message-ID: <542169DC.2060207@huawei.com> Date: Tue, 23 Sep 2014 20:38:52 +0800 From: zhanghailiang MIME-Version: 1.0 References: <1410863956-11056-1-git-send-email-zhang.zhanghailiang@huawei.com> <1410863956-11056-2-git-send-email-zhang.zhanghailiang@huawei.com> <20140917083220.GA17032@G08FNSTD100614.fnst.cn.fujitsu.com> <20140919142642.7d7fbd3d@nial.usersys.redhat.com> <541FE5D0.9050705@cn.fujitsu.com> <20140923104047.4ef196f9@nial.usersys.redhat.com> <54213648.5070608@cn.fujitsu.com> <54214757.7080806@huawei.com> <20140923131218.223e9e20@nial.usersys.redhat.com> In-Reply-To: <20140923131218.223e9e20@nial.usersys.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] pc-dimm: No numa option shouldn't break hotplug memory feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Peter , mst@redhat.com, qemu-devel@nongnu.org, Hu Tao , luonengjun@huawei.com, peter.huangpeng@huawei.com, Tang Chen , pbonzini@redhat.com, gaowanlong@cn.fujitsu.com On 2014/9/23 19:12, Igor Mammedov wrote: > On Tue, 23 Sep 2014 18:11:35 +0800 > zhanghailiang wrote: > >> On 2014/9/23 16:58, Tang Chen wrote: >>> >>> On 09/23/2014 04:40 PM, Igor Mammedov wrote: >>>> ...... >>>> It's fine to use SRAT for these purposes on baremetal NUMA systems since >>>> due to used chipset constrains it's possible statically allocate ranges >>>> for every possible DIMM socket. >>>> However SRAT(which is optional table BTW) entries are not mandatory >>>> and override-able by ACPI Device's _PXM/_CRS methods replacing needs >>>> for SRAT entries and QEMU uses this fact by supplying these methods. >>>> QEMU adds FAKE SRAT entry only to workaround Windows limitation, >>>> and for nothing else. >>>> >>>> I think Linux does not violate ACPI spec and behaves as expected, moreover >>>> it's more correct than Windows since memory hotplug will work on non NUMA >>>> machines as well. >>>> >>>> Hence I think this patch is correct and allows memory hotplug in absence >>>> of NUMA configuration. It also would allow to use pc-dimm as replacement >>>> for initial memory for non-NUMA configs (which is on my TODO list) >>>> >>>> As for the Windows, QEMU has no idea what OS it would be running, >>>> I see 2 ways to solve issue: >>>> 1. user should know that memory hotplug on Windows requires NUMA machine >>>> and specify "-numa ..." option for this case. >>>> (I've discussed this with libvirt folks and was promised that >>>> if user enables memory hotplug, libvirt would provide "-numa" option >>>> to workaround Windows issue) >>>> >>>> 2. QEMU could unconditionally create single NUMA if memory hotplug is >>>> enabled. (but that should be enable only for 2.2 or late machines >>>> to avoid migration issues) >>>> >>> I prefer 2. I'll try to send patches for it if Zhang is also OK with it. >>> >> >> Yep, It is a good scheme to create a dummy NUMA unconditionally. >> But Igor has said there are migration issues for this scenario, do you know what's >> it? ;) >> > '-numa' will add SRAT table to ACPI tables blob, as result it will grow in size, > depending on config options #cpus, #dimms, #pci-bridges it could trigger > issues we've had with prior 2.1 was released. Hmm, i guess i know what happened, i have found in function acpi_build there are annotations for the migration issue... I will look deep into it, Thanks for your patient explanation.:)