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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FAKE_REPLY_C,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 2FCBBC433EF for ; Fri, 3 Sep 2021 09:33:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 135C160F91 for ; Fri, 3 Sep 2021 09:33:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348822AbhICJea (ORCPT ); Fri, 3 Sep 2021 05:34:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244272AbhICJe3 (ORCPT ); Fri, 3 Sep 2021 05:34:29 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EDB8C061575 for ; Fri, 3 Sep 2021 02:33:30 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id t12so10431509lfg.9 for ; Fri, 03 Sep 2021 02:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=KjJsqN08kHUU9hALt64x49WnpC13zTqRn/N/C5PoLnI=; b=He+DQLj1WT4ORQvv8S8uq3EujtuxuAoiAyYvQc2ErhJjuczXlaIpOjYjhIVCMJATEz 80xdA8ILn36S+tN8GvvvJPkhIOdmeFZRSsvpDwoWyLVQ1nnx6A7yzxrk8wu9pJ2l5Mvy rvzqVbcxFDJlCzlm4/re12fXzraSap97kpHA9QFoBK3JFctamfb6SXFSWybcO9HWnqIB mwNyO5WFnyIk+bAkYn19W24fOzfNEjs84BZR0ZO1yg8EjhYW2FiCWXMVXzyc2CdMXGqn CrhY+rDqCpKsDiac/AF1EHBVxLLsDmOfynzOYta5aRjiab/Obf1dDdcEsesypl//6QQA TIVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=KjJsqN08kHUU9hALt64x49WnpC13zTqRn/N/C5PoLnI=; b=N5oeTpx7yK8ytpzl3PzmcYOVC+GYqKslFoTkkyhOyUzVOBsEkRS/aaFNISwBFWMVoB RmV05I6Oh4p+uV78XWFEy8/eEwG+wti1jReOmxbXvmlpfR/2JuInelkiZTy0Zfcad/Ot wkpQGGODFspSIydqFg5GmZljipx5ldqMNT8EDQOyGCm5HFdhmAatugMXUBy4KgrXY1Tz 7JG5r/WU+zgu8zJeBsccOe27BMuLHcKFpMxWeyo0cAPDDRXiBjh8i+yW0D4WOoggr2Cz 8lkrTAMC2Qyw2N39rNNxdW+x6whbo1uQYK8BgNqZBUE8c6L4gHFBHAmiwYDCz09Mep/E o+Nw== X-Gm-Message-State: AOAM532I6i03frviSa4HefHolvuW4e6vonwR5b84aGaw8k+Jc6Mn8i9k p2ItuuLoZ4Li/i5Fb/PmrHqxvr8UsgWEZHk/lm4= X-Google-Smtp-Source: ABdhPJxifj1S2SHPbc+Df6lhpY7062s4mIlcoloXqCBFD+lRLnj9An5kt3UKL3ju1PFjr0wwJknX0A== X-Received: by 2002:a19:c350:: with SMTP id t77mr2032018lff.33.1630661608232; Fri, 03 Sep 2021 02:33:28 -0700 (PDT) Received: from zombie ([176.106.247.78]) by smtp.gmail.com with ESMTPSA id z11sm524805ljn.114.2021.09.03.02.33.27 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Sep 2021 02:33:27 -0700 (PDT) Date: Fri, 3 Sep 2021 12:33:25 +0300 From: Valeriy Vdovin To: Markus Armbruster Cc: "qemu-devel@nongnu.org" , Thomas Huth , Marcel Apfelbaum , Eric Blake , Paolo Bonzini , Marcelo Tosatti , Richard Henderson , Laurent Vivier , kvm@vger.kernel.org, Denis Lunev , Vladimir Sementsov-Ogievskiy , Valeriy Vdovin Subject: Re: [PATCH v12] qapi: introduce 'query-x86-cpuid' QMP command. Message-ID: <20210903093325.GA26525@zombie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735qzpccg.fsf@dusky.pond.sub.org> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 24 Aug 2021 08:48:31 +0200 Marcus Armbruster wrote: >Eduardo Habkost writes: > >> On Mon, Aug 23, 2021 at 9:35 AM Markus Armbruster wrote: >>> >>> Eduardo Habkost writes: >>> >>> > On Wed, Aug 11, 2021 at 9:44 AM Thomas Huth wrote: >>> >> >>> >> On 11/08/2021 15.40, Eduardo Habkost wrote: >>> >> > On Wed, Aug 11, 2021 at 2:10 AM Thomas Huth wrote: >>> >> >> >>> >> >> On 10/08/2021 20.56, Eduardo Habkost wrote: >>> >> >>> On Sat, Aug 07, 2021 at 04:22:42PM +0200, Markus Armbruster wrote: >>> >> >>>> Is this intended to be a stable interface? Interfaces intended just >>> >> >>>> for >>> >> >>>> debugging usually aren't. >>> >> >>> >>> >> >>> I don't think we need to make it a stable interface, but I won't >>> >> >>> mind if we declare it stable. >>> >> >> >>> >> >> If we don't feel 100% certain yet, it's maybe better to introduce this >>> >> >> with >>> >> >> a "x-" prefix first, isn't it? I.e. "x-query-x86-cpuid" ... then it's >>> >> >> clear >>> >> >> that this is only experimental/debugging/not-stable yet. Just my 0.02 >>> >> >> €. >>> >> > >>> >> > That would be my expectation. Is this a documented policy? >>> >> > >>> >> >>> >> According to docs/interop/qmp-spec.txt : >>> >> >>> >> Any command or member name beginning with "x-" is deemed >>> >> experimental, and may be withdrawn or changed in an incompatible >>> >> manner in a future release. >>> > >>> > Thanks! I had looked at other QMP docs, but not qmp-spec.txt. >>> > >>> > In my reply above, please read "make it a stable interface" as >>> > "declare it as supported by not using the 'x-' prefix". >>> > >>> > I don't think we have to make it stable, but I won't argue against it >>> > if the current proposal is deemed acceptable by other maintainers. >>> > >>> > Personally, I'm still frustrated by the complexity of the current >>> > proposal, but I don't want to block it just because of my frustration. >>> >>> Is this a case of "there must be a simpler way", or did you actually >>> propose a simpler way? I don't remember... >>> >> >> I did propose a simpler way at >> 20210810195053.6vsjadglrexf6jwy@habkost.net/">https://lore.kernel.org/qemu-devel/20210810195053.6vsjadglrexf6jwy@habkost.net/ > Hi. Sorry for the late response to that. Also sorry for possible technical email header errors in my reply mail, as I was switching the e-mail accounts that I use to communicate with this maillist, so hope technically all went well. >Valeriy, would the simpler way still work for you? > >If no, please explain why. If you already did, just provide a pointer. > Yes, I remember your proposal of using just 5 lines of code. To be exact here are those proposed lines: >> for start in (0, 0x40000000, 0x80000000, 0xC0000000): >> leaf = query_cpuid(qom_path, start) >> for eax in range(start, leaf.max_eax + 1): >> for ecx in range(0, leaf.get('max_ecx', 0) + 1): >> all_leaves.append(query_cpuid(qom_path, eax, ecx)) It looks cool and short, but this is only a pseudocode with not only variable declarations omitted, but with some logic omitted as well. It does not become obvious until you start typing the code and then review it. In fact the patch, to which you have done this suggestion back then already had the same concept at it's basis, but it has grown quickly to somewhat more complex code than it's conceptual pseudo-brother above. I'm sure that this current patch (which is the most recent in v15 email) is the most simple and shortest of possible. This is iteration 3 patch, with first iteration being the one to which you've made that suggestion, but then we also tried one more version by trying to do this via KVM ioctls, but it did not work quite smooth. So this last iteration at which we are currently looking at is really the product of thought and is the simplest. I suggest that we stick to it and start converging towards it's submission instead of going to another round of coding and discussion. v15 - is the result of fine-tunes and rebases, that has already covered a lot of comments. Please let's review it to the end and give it a go. >If yes, we need to choose between the complex solution we have and the >simpler solution we still need to code up. The latter is extra work, >but having to carry more complex code is going to be extra work, too. I agree to the idea that we MUST minimize support effort in priority to the commiting effort, but here I do not see direct dependency between the two. This is already the simplest solution. All the code we have here is mostly to service the QMP machinery, which has to be in any version of the patch. The payload code is minimal. Thanks. 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.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FAKE_REPLY_C,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 D1FE1C433EF for ; Fri, 3 Sep 2021 09:34:34 +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 6867960698 for ; Fri, 3 Sep 2021 09:34:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6867960698 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:41612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mM5aj-0001oR-La for qemu-devel@archiver.kernel.org; Fri, 03 Sep 2021 05:34:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM5Zk-0007dP-VU for qemu-devel@nongnu.org; Fri, 03 Sep 2021 05:33:32 -0400 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:33480) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mM5Zj-0004CT-2k for qemu-devel@nongnu.org; Fri, 03 Sep 2021 05:33:32 -0400 Received: by mail-lf1-x12f.google.com with SMTP id p38so10696414lfa.0 for ; Fri, 03 Sep 2021 02:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=KjJsqN08kHUU9hALt64x49WnpC13zTqRn/N/C5PoLnI=; b=He+DQLj1WT4ORQvv8S8uq3EujtuxuAoiAyYvQc2ErhJjuczXlaIpOjYjhIVCMJATEz 80xdA8ILn36S+tN8GvvvJPkhIOdmeFZRSsvpDwoWyLVQ1nnx6A7yzxrk8wu9pJ2l5Mvy rvzqVbcxFDJlCzlm4/re12fXzraSap97kpHA9QFoBK3JFctamfb6SXFSWybcO9HWnqIB mwNyO5WFnyIk+bAkYn19W24fOzfNEjs84BZR0ZO1yg8EjhYW2FiCWXMVXzyc2CdMXGqn CrhY+rDqCpKsDiac/AF1EHBVxLLsDmOfynzOYta5aRjiab/Obf1dDdcEsesypl//6QQA TIVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=KjJsqN08kHUU9hALt64x49WnpC13zTqRn/N/C5PoLnI=; b=DkU4ViZVkVs4K9x19t6tZA53kBZlhBP0uxgs6NloOqo97Wsk3AIj76T9bQSE/XHkH6 RX6P7TWhdUda9TCB5lEJdKvIsnW0XlcFr0COsZZFTInIMUS4WoBpwb3elwK4pA7JKkBy NNhsEoW7sd+FMiINa9k7Pz4kR8TBxXHQoG2EsgKf1EPuEDsItonOsjD5cZnp5+IAWhLr zM1IXADM6X+xWwqJ0Zrl7cKYa+OmmL3WAm7UFHvckF2FK/bSOnimvqw55rDUxS2D54E8 DS3dXFpculx4r8gv4B1a+tiWFyub4EEgQk24pVr5LAhci5b8d9uqpwBM5YxagZ6HRaTY cvgA== X-Gm-Message-State: AOAM531t16Q8t2fY/5VLHd/aQqR+fK/RzALh7vdm/+lFh8BbmeuRg4oB ywbFXLfEQ+jC4iWrLO3bBlg= X-Google-Smtp-Source: ABdhPJxifj1S2SHPbc+Df6lhpY7062s4mIlcoloXqCBFD+lRLnj9An5kt3UKL3ju1PFjr0wwJknX0A== X-Received: by 2002:a19:c350:: with SMTP id t77mr2032018lff.33.1630661608232; Fri, 03 Sep 2021 02:33:28 -0700 (PDT) Received: from zombie ([176.106.247.78]) by smtp.gmail.com with ESMTPSA id z11sm524805ljn.114.2021.09.03.02.33.27 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 Sep 2021 02:33:27 -0700 (PDT) Date: Fri, 3 Sep 2021 12:33:25 +0300 From: Valeriy Vdovin To: Markus Armbruster Subject: Re: [PATCH v12] qapi: introduce 'query-x86-cpuid' QMP command. Message-ID: <20210903093325.GA26525@zombie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735qzpccg.fsf@dusky.pond.sub.org> User-Agent: Mutt/1.9.4 (2018-02-28) Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=valery.vdovin.s@gmail.com; helo=mail-lf1-x12f.google.com X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FAKE_REPLY_C=1.486, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: Laurent Vivier , Thomas Huth , Vladimir Sementsov-Ogievskiy , kvm@vger.kernel.org, Valeriy Vdovin , Marcelo Tosatti , Richard Henderson , "qemu-devel@nongnu.org" , Denis Lunev , Paolo Bonzini , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 24 Aug 2021 08:48:31 +0200 Marcus Armbruster wrote: >Eduardo Habkost writes: > >> On Mon, Aug 23, 2021 at 9:35 AM Markus Armbruster wrote: >>> >>> Eduardo Habkost writes: >>> >>> > On Wed, Aug 11, 2021 at 9:44 AM Thomas Huth wrote: >>> >> >>> >> On 11/08/2021 15.40, Eduardo Habkost wrote: >>> >> > On Wed, Aug 11, 2021 at 2:10 AM Thomas Huth wrote: >>> >> >> >>> >> >> On 10/08/2021 20.56, Eduardo Habkost wrote: >>> >> >>> On Sat, Aug 07, 2021 at 04:22:42PM +0200, Markus Armbruster wrote: >>> >> >>>> Is this intended to be a stable interface? Interfaces intended just >>> >> >>>> for >>> >> >>>> debugging usually aren't. >>> >> >>> >>> >> >>> I don't think we need to make it a stable interface, but I won't >>> >> >>> mind if we declare it stable. >>> >> >> >>> >> >> If we don't feel 100% certain yet, it's maybe better to introduce this >>> >> >> with >>> >> >> a "x-" prefix first, isn't it? I.e. "x-query-x86-cpuid" ... then it's >>> >> >> clear >>> >> >> that this is only experimental/debugging/not-stable yet. Just my 0.02 >>> >> >> €. >>> >> > >>> >> > That would be my expectation. Is this a documented policy? >>> >> > >>> >> >>> >> According to docs/interop/qmp-spec.txt : >>> >> >>> >> Any command or member name beginning with "x-" is deemed >>> >> experimental, and may be withdrawn or changed in an incompatible >>> >> manner in a future release. >>> > >>> > Thanks! I had looked at other QMP docs, but not qmp-spec.txt. >>> > >>> > In my reply above, please read "make it a stable interface" as >>> > "declare it as supported by not using the 'x-' prefix". >>> > >>> > I don't think we have to make it stable, but I won't argue against it >>> > if the current proposal is deemed acceptable by other maintainers. >>> > >>> > Personally, I'm still frustrated by the complexity of the current >>> > proposal, but I don't want to block it just because of my frustration. >>> >>> Is this a case of "there must be a simpler way", or did you actually >>> propose a simpler way? I don't remember... >>> >> >> I did propose a simpler way at >> 20210810195053.6vsjadglrexf6jwy@habkost.net/">https://lore.kernel.org/qemu-devel/20210810195053.6vsjadglrexf6jwy@habkost.net/ > Hi. Sorry for the late response to that. Also sorry for possible technical email header errors in my reply mail, as I was switching the e-mail accounts that I use to communicate with this maillist, so hope technically all went well. >Valeriy, would the simpler way still work for you? > >If no, please explain why. If you already did, just provide a pointer. > Yes, I remember your proposal of using just 5 lines of code. To be exact here are those proposed lines: >> for start in (0, 0x40000000, 0x80000000, 0xC0000000): >> leaf = query_cpuid(qom_path, start) >> for eax in range(start, leaf.max_eax + 1): >> for ecx in range(0, leaf.get('max_ecx', 0) + 1): >> all_leaves.append(query_cpuid(qom_path, eax, ecx)) It looks cool and short, but this is only a pseudocode with not only variable declarations omitted, but with some logic omitted as well. It does not become obvious until you start typing the code and then review it. In fact the patch, to which you have done this suggestion back then already had the same concept at it's basis, but it has grown quickly to somewhat more complex code than it's conceptual pseudo-brother above. I'm sure that this current patch (which is the most recent in v15 email) is the most simple and shortest of possible. This is iteration 3 patch, with first iteration being the one to which you've made that suggestion, but then we also tried one more version by trying to do this via KVM ioctls, but it did not work quite smooth. So this last iteration at which we are currently looking at is really the product of thought and is the simplest. I suggest that we stick to it and start converging towards it's submission instead of going to another round of coding and discussion. v15 - is the result of fine-tunes and rebases, that has already covered a lot of comments. Please let's review it to the end and give it a go. >If yes, we need to choose between the complex solution we have and the >simpler solution we still need to code up. The latter is extra work, >but having to carry more complex code is going to be extra work, too. I agree to the idea that we MUST minimize support effort in priority to the commiting effort, but here I do not see direct dependency between the two. This is already the simplest solution. All the code we have here is mostly to service the QMP machinery, which has to be in any version of the patch. The payload code is minimal. Thanks.