From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWO6G-0006dU-Mo for qemu-devel@nongnu.org; Tue, 23 Sep 2014 07:17:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWO6B-0004Un-T5 for qemu-devel@nongnu.org; Tue, 23 Sep 2014 07:17:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWO6B-0004U6-K7 for qemu-devel@nongnu.org; Tue, 23 Sep 2014 07:17:35 -0400 Date: Tue, 23 Sep 2014 13:12:18 +0200 From: Igor Mammedov Message-ID: <20140923131218.223e9e20@nial.usersys.redhat.com> In-Reply-To: <54214757.7080806@huawei.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 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 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.