From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWNMo-0002O0-NU for qemu-devel@nongnu.org; Tue, 23 Sep 2014 06:30:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWNMj-0000M7-AC for qemu-devel@nongnu.org; Tue, 23 Sep 2014 06:30:42 -0400 Received: from [59.151.112.132] (port=44588 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWNMi-0000KP-Qh for qemu-devel@nongnu.org; Tue, 23 Sep 2014 06:30:37 -0400 Message-ID: <54214C28.4080109@cn.fujitsu.com> Date: Tue, 23 Sep 2014 18:32:08 +0800 From: Tang Chen 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> In-Reply-To: <54214757.7080806@huawei.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: zhanghailiang , Igor Mammedov Cc: Peter , mst@redhat.com, Hu Tao , luonengjun@huawei.com, peter.huangpeng@huawei.com, qemu-devel@nongnu.org, pbonzini@redhat.com, gaowanlong@cn.fujitsu.com On 09/23/2014 06:11 PM, 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? ;) Not sure. This one ? https://www.mail-archive.com/qemu-devel%40nongnu.org/msg249146.html Thanks. :) > > . >