From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F09CC07E9B for ; Mon, 19 Jul 2021 15:52:08 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AD57261248 for ; Mon, 19 Jul 2021 15:52:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD57261248 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5VYs-0006Z0-QJ for qemu-devel@archiver.kernel.org; Mon, 19 Jul 2021 11:52:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53054) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5VXv-0005UF-Ew for qemu-devel@nongnu.org; Mon, 19 Jul 2021 11:51:07 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:31023) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5VXt-0006Sj-So for qemu-devel@nongnu.org; Mon, 19 Jul 2021 11:51:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626709865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aURnSvW7tUpg2fZDJYV2UtY/MNIqSLql1s392+QUjlw=; b=awuKK4N1Egt5FONawNJi99ljZpbakFrjXMwnvMJfsuhdsQ/wV79seVXrkTjKeTzFL+E9Mw aqlp1YxE+nB0O8KxJ3WoTpjrMkvx/v7K2VZUnv+x1gkpybPXGVrh5tut6xa7ckDfPwYaGN gp8Of8P/j5tA1o/i3hKKirO4Tet5J6g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-H-n8fx3uNQWXX191XXrIfg-1; Mon, 19 Jul 2021 11:50:59 -0400 X-MC-Unique: H-n8fx3uNQWXX191XXrIfg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D31A6195D560; Mon, 19 Jul 2021 15:50:57 +0000 (UTC) Received: from localhost (ovpn-112-158.ams2.redhat.com [10.36.112.158]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DEECB60CA0; Mon, 19 Jul 2021 15:50:53 +0000 (UTC) From: Cornelia Huck To: =?utf-8?Q?Daniel_P=2E_Berrang=C3=A9?= Subject: Re: [PATCH v1 2/9] s390x: toplogy: adding drawers and books to smp parsing In-Reply-To: Organization: Red Hat GmbH References: <1626281596-31061-1-git-send-email-pmorel@linux.ibm.com> <1626281596-31061-3-git-send-email-pmorel@linux.ibm.com> <87y2a8cda7.fsf@dusky.pond.sub.org> <0801e122-0e9c-e266-42e8-d5cddb16c237@linux.ibm.com> <87bl73df9y.fsf@dusky.pond.sub.org> <87y2a6bp5f.fsf@redhat.com> <87pmvibkri.fsf@redhat.com> User-Agent: Notmuch/0.32.1 (https://notmuchmail.org) Date: Mon, 19 Jul 2021 17:50:52 +0200 Message-ID: <87czre9uar.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=cohuck@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=170.10.133.124; envelope-from=cohuck@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.469, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: thuth@redhat.com, ehabkost@redhat.com, Pierre Morel , david@redhat.com, richard.henderson@linaro.org, Markus Armbruster , qemu-devel@nongnu.org, pasic@linux.ibm.com, borntraeger@de.ibm.com, qemu-s390x@nongnu.org, pbonzini@redhat.com, eblake@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Jul 16 2021, Daniel P. Berrang=C3=A9 wrote: > On Fri, Jul 16, 2021 at 12:44:49PM +0200, Cornelia Huck wrote: >> On Fri, Jul 16 2021, Daniel P. Berrang=C3=A9 wrote= : >>=20 >> > On Fri, Jul 16, 2021 at 11:10:04AM +0200, Cornelia Huck wrote: >> >> On Thu, Jul 15 2021, Markus Armbruster wrote: >> >>=20 >> >> > Pierre Morel writes: >> >> > >> >> >> On 7/15/21 8:16 AM, Markus Armbruster wrote: >> >> >>> Pierre Morel writes: >> >> >>>=20 >> >> >>>> Drawers and Books are levels 4 and 3 of the S390 CPU >> >> >>>> topology. >> >> >>>> We allow the user to define these levels and we will >> >> >>>> store the values inside the S390CcwMachineState. >> >> >>>=20 >> >> >>> Double-checking: are these members specific to S390? >> >> >> >> >> >> Yes AFAIK >> >> > >> >> > Makes me wonder whether they should be conditional on TARGET_S390X. >> >> > >> >> > What happens when you specify them for another target? Silently >> >> > ignored, or error? >> >>=20 >> >> I'm wondering whether we should include them in the base machine stat= e >> >> and treat them as we treat 'dies' (i.e. the standard parser errors ou= t >> >> if they are set, and only the s390x parser supports them.) >> > >> > To repeat what i just wrote in my reply to patch 1, I think we ought t= o >> > think about a different approach to handling the usage constraints, >> > which doesn't require full re-implementation of the smp_parse method >> > each time. There should be a way for each target to report topology >> > constraints, such the the single smp_parse method can do the right >> > thing, especially wrt error reporting for unsupported values. >>=20 >> That would mean that all possible fields would need to go into common >> code, right? > > Yes, that is an implication of what i'm suggesting. > >> I'm wondering whether there are more architecture/cpu specific values >> lurking in the corner, it would get unwieldy if we need to go beyond the >> existing fields and drawers/books. > > Is the book/drawer thing architecture specific, or is it machine > type / CPU specific. ie do /all/ the s390x machine types / CPUS > QEMU support the book/drawer concept, or only a subset. Should not be by machine type, but might be by cpu model (e.g. older hardware lacking the needed support for exposing this to the guest.) IBM folks, please correct me if I'm wrong. > If only a subset, then restricting it per target on QAPI doesn't > fully solve the root problem, and we instead are better focusing > on accurate runtime error reporting. Nod. Runtime error reporting should also be more flexible.