From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqGtE-0005Ik-79 for qemu-devel@nongnu.org; Mon, 26 Feb 2018 06:24:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqGtA-0001yF-AK for qemu-devel@nongnu.org; Mon, 26 Feb 2018 06:24:16 -0500 Date: Mon, 26 Feb 2018 12:23:56 +0100 From: Cornelia Huck Message-ID: <20180226122356.111c4b1d.cohuck@redhat.com> In-Reply-To: References: <20180223173657.29125-1-david@redhat.com> <20180226111953.1e9bc50c.cohuck@redhat.com> <20180226113503.6ecfa712.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1] numa: s390x has no NUMA List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: David Hildenbrand , qemu-s390x@nongnu.org, qemu-devel@nongnu.org, Eduardo Habkost On Mon, 26 Feb 2018 12:07:43 +0100 Christian Borntraeger wrote: > On 02/26/2018 11:35 AM, Cornelia Huck wrote: > > On Mon, 26 Feb 2018 11:28:26 +0100 > > David Hildenbrand wrote: > > > >> On 26.02.2018 11:19, Cornelia Huck wrote: > >>> On Fri, 23 Feb 2018 18:36:57 +0100 > >>> David Hildenbrand wrote: > >>> > >>>> Right now it is possible to crash QEMU for s390x by providing e.g. > >>>> -numa node,nodeid=0,cpus=0-1 > >>>> > >>>> Problem is, that numa.c uses mc->cpu_index_to_instance_props as an > >>>> indicator whether NUMA is supported by a machine type. We don't > >>>> implement NUMA on s390x (and that concept also doesn't really exist). > >>>> We need mc->cpu_index_to_instance_props for query-cpus. > >>> > >>> Is existence of cpu_index_to_instance_probs the correct indicator for > >>> numa, then? > >>> > >>> OTOH, your patch is straightforward... > >> > >> Maybe it is get_default_cpu_node_id as Christian discovered? > > > > Yes, that seems like a better candidate for checking. > > Agreed. > As everybody else calls possible_cpu_arch_ids in cpu_index_to_props > I am asking myself if we should do that as well anyway? > Making the behaviour consistent with other archs sounds like a good idea.