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=-0.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,HTML_OBFUSCATE_05_10, 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 8C621C433ED for ; Fri, 14 May 2021 18:35:13 +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 E4DCE61132 for ; Fri, 14 May 2021 18:35:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4DCE61132 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]:41536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhceV-0007mJ-Qr for qemu-devel@archiver.kernel.org; Fri, 14 May 2021 14:35:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhccE-0004nL-89 for qemu-devel@nongnu.org; Fri, 14 May 2021 14:32:50 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:44913) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhcc9-0004D7-En for qemu-devel@nongnu.org; Fri, 14 May 2021 14:32:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621017164; 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: in-reply-to:in-reply-to:references:references; bh=5EcjNFRyCRzTO9haFGaaz/JwjD0xYxlrSQS/Pc3/Bas=; b=U16qkY2LYK9SY23e2oT5znkVoVYVwMFDCjdTwqMgA0IFY1v6Wo68Ris5JXod7TVNgSwiTp Hl6p0o/HtrxauOWqhqOc1ldoYuTuLlPl2c25DxN9QoaakyLQsYwEImSWvIDfvWhGeREqGG k/4fPnbC3QwlrpPIo64O1LwXSFDhmFQ= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-526-me7GUhpqMKWb0X3hoX-dfQ-1; Fri, 14 May 2021 14:32:37 -0400 X-MC-Unique: me7GUhpqMKWb0X3hoX-dfQ-1 Received: by mail-pj1-f72.google.com with SMTP id l15-20020a17090ac58fb029015718e39aa2so327818pjt.6 for ; Fri, 14 May 2021 11:32:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5EcjNFRyCRzTO9haFGaaz/JwjD0xYxlrSQS/Pc3/Bas=; b=fkDglRPSIAujbXva0Ho8Prdp2mPiIBo51A8DwOtv/shBdEhyXKMMofL0S6B1fmAcrd BAkzonOZbKRzZLRVeBVeSGhsjM6sVQkM6EXAxyN75M8EENmfqbF0q6rii64gaYZvKR5L Z03v8D5bBWiBvQdTT/9wEnmGO0iRJrXEBiAwiwSL9ndhjqLwJLTEuTCNS4ha8W3S/yyh Pvp4a7pzXNLO7AAxm5Qb37C0Alu9QP9aK2FaOy4Bzlr90fRE1pFAfY7HQIe+M4W4Dfd/ 1AC8jslFbUfBd8eoSE7mDYWg2y3aFK/JPW5ZsmgO0V53+WDmNRQTzpasaZlraZhxGeP3 Mkkw== X-Gm-Message-State: AOAM533WnA+SGnQn5RxdfvFNNflMuhNONj08A1GaE93lPxSbhsPteAD9 icDfmQdbl3+nluawj4iYlykZzhi16D7gI+xiVs0kp57SHLa+i0yf2vRIHyxZ0NJRqqLf+Gf0BSf jBK5Pa1MnljKq7g041MtiwgWfxvz6Zt8= X-Received: by 2002:a05:6a00:14cb:b029:2be:1466:5a28 with SMTP id w11-20020a056a0014cbb02902be14665a28mr27757334pfu.55.1621017155904; Fri, 14 May 2021 11:32:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKysFxsBx9QgxuciGcZHp03D20QwrOUrKNNa6kVbAwJ6GW+XpjvB366EVguB/gnsNI+U/znkW47zdH5FRIWBg= X-Received: by 2002:a05:6a00:14cb:b029:2be:1466:5a28 with SMTP id w11-20020a056a0014cbb02902be14665a28mr27757303pfu.55.1621017155613; Fri, 14 May 2021 11:32:35 -0700 (PDT) MIME-Version: 1.0 References: <20210513082549.114275-1-mirela.grujic@greensocs.com> <93ae82d3-f9a7-f347-a013-54ae5cdc95f7@redhat.com> <5210646b-c661-882d-6c8d-0fd1772342d2@greensocs.com> <61071d36-b700-8546-c19b-09c4e582bdfe@redhat.com> In-Reply-To: From: Paolo Bonzini Date: Fri, 14 May 2021 20:32:22 +0200 Message-ID: Subject: Re: [RFC PATCH 0/9] Initial support for machine creation via QMP To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000bc501105c24e7747" Received-SPF: pass client-ip=170.10.133.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.699, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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: Damien Hedde , "Edgar E . Iglesias" , Mirela Grujic , Mark Burton , qemu-devel Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000bc501105c24e7747 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Il ven 14 mag 2021, 18:20 Daniel P. Berrang=C3=A9 ha scritto: > My gut feeling though is accel-set would be more logical being done > first, as that also influences the set of features available in other > areas of QEMU configuration. Was there a reason you listed it after > machine-set ? > That was also my initial gut feeling, but actually right now the machine influences the accelerator more than the other way round. For example the initialization of the accelerator takes a machine so that for example on x86 the per-architecture KVM knows whether to set up SMM. Also different machines could use different modes for KVM (HV vs PR for ppc), and some machines may not be virtualizable at all so they require TCG. The host CPU these days is really a virtualization-only synonym for -cpu max, which works for TCG as well. But you're right that x86 CPU flags are dictated by the accelerator rather than the machine, so specifying it in machine-set would be clumsy. On the other hand on ARM it's a bit of both: for KVM it's basically always -cpu host so the accelerator is important; but some machines may have an M profile CPU and some may have an A. I don't have the sources at hand to check in which phase CPUs are created, but it's definitely after ACCEL_CREATED. Adding a third command cpu-model-set is probably the easiest way to proceed. Paolo > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > --000000000000bc501105c24e7747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Il ven 14 mag 2021, 18:20 Daniel P. Berrang=C3=A9 <= berrange@redhat.com> ha scrit= to:
My gut feeling though is accel-= set would be more logical being done
first, as that also influences the set of features available in other
areas of QEMU configuration. Was there a reason you listed it after
machine-set ?

That was also my initial gut feeling, but actually right now t= he machine influences the accelerator more than the other way round. For ex= ample the initialization of the acce= lerator takes a machine so that for example on x86 the per-architecture KVM= knows whether to set up SMM. Also different machines could use diff= erent modes for KVM (HV vs PR for ppc), and some machines may not be virtua= lizable at all so they require TCG.

The host CPU these days is really a virtualization-only synonym= for -cpu max, which works for TCG as well. But you're right that x86 C= PU flags are dictated by the accelerator rather than the machine, so specif= ying it in machine-set would be clumsy. On the other hand on ARM it's a= bit of both: for KVM it's basically always -cpu host so the accelerato= r is important; but some machines may have an M profile CPU and some may ha= ve an A.

I don't hav= e the sources at hand to check in which phase CPUs are created, but it'= s definitely after ACCEL_CREATED. Adding a third command cpu-model-set is p= robably the easiest way to proceed.

Paolo


Regards,
Daniel
--
|: https://berrange.com=C2=A0 =C2=A0 =C2=A0 -o-=C2=A0 =C2=A0 https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-o-=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://fstop138.berrange= .com :|
|: https://entangle-photo.org=C2=A0 =C2=A0 -o-=C2=A0 =C2=A0= https://www.instagram.com/dberrange :|

--000000000000bc501105c24e7747--