[{"id":3190017,"web_url":"http://patchwork.ozlabs.org/comment/3190017/","msgid":"","list_archive_url":null,"date":"2023-09-29T10:10:22","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":66817,"url":"http://patchwork.ozlabs.org/api/people/66817/","name":"Andrea Bolognani","email":"abologna@redhat.com"},"content":"On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n> Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n> (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n>\n> Hi,\n>\n> These patches implements the base profile support for qemu-riscv and the\n> first profile, RVA22U64.\n>\n> As discussed in this thread [1] we're aiming for a flag that enables all\n> mandatory extensions of a profile. Optional extensions were left behind\n> and must be enabled by hand if desired. Since this is the first profile\n> we're adding, we'll need to add the base framework as well.\n>\n> The RVA22U64 profile was chosen because qemu-riscv implements all its\n> extensions, both mandatory and optional. That includes 'zicntr' and\n> 'zihpm', which we support for awhile but aren't adverting to userspace.\n>\n> Other design decisions made:\n>\n> - disabling a profile flag does nothing, i.e. we won't mass disable\n> mandatory extensions of the rva22U64 profile if the user sets\n> rva22u64=false;\n\nWouldn't it make more sense to error out when this is requested?\n\nSilently ignoring an explicit request made by the user is pretty much\nnever a good idea in my experience.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=DffnLZPY;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RxmNP32tKz1yp0\n\tfor ; Fri, 29 Sep 2023 20:11:48 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmAS7-00043g-CL; Fri, 29 Sep 2023 06:10:31 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmAS5-00041y-Dj\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 06:10:29 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.133.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmAS3-0007Uj-RQ\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 06:10:29 -0400","from mail-qt1-f197.google.com (mail-qt1-f197.google.com\n [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-284-nXxkpJhyO9iyhiRw3vtksA-1; Fri, 29 Sep 2023 06:10:24 -0400","by mail-qt1-f197.google.com with SMTP id\n d75a77b69052e-4197fa36adaso3014321cf.1\n for ; Fri, 29 Sep 2023 03:10:23 -0700 (PDT)","from 744723338238 named unknown by gmailapi.google.com with\n HTTPREST; Fri, 29 Sep 2023 03:10:22 -0700"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1695982225;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=AmW8J85dENOAgEDN98oOAMNFnCixUejLydCPc+GbG3c=;\n b=DffnLZPYGtjrAi3uF88ecCYPz6jzzs+fj8tujT71CQv8gsFEc36NDgR6QVuNdpOHQHLHuF\n GapC42fkSeauj/PS0wvZQ6YLYbjaOej80TAOuBRdqi3MuSW+Wy0DnyEPpnjTbuTvQ0uJbV\n wjKqDe+Umo11Aiw76BoQygDdsbuQWBg=","X-MC-Unique":"nXxkpJhyO9iyhiRw3vtksA-1","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1695982223; x=1696587023;\n h=cc:to:subject:message-id:date:in-reply-to:mime-version:references\n :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=AmW8J85dENOAgEDN98oOAMNFnCixUejLydCPc+GbG3c=;\n b=N/D0u5Sl99jp0XSXAJWbZRQb8kyENjXAUDL4dXXksksgHl0g+Fd5rwA2guGq/EtmmU\n 2fEAYO9Wu1y4doKRm1B5ss2oVpKm8AzjKzfz9PebdskH08ElBZ83akK1Zn7Fd5q4erV8\n XpLE6Gdqv93dLpsHiAQkw2+YuT01Rrgm07zLpBn+4f1LK7QWHIePWqPK2jR6OOyZU+2m\n MrTR5tRwxoO3VM4/PIDsV5ph8wyiCigmolrFJFWZ/HtZdrmHlOmAm1ecSAOr0ce7upxQ\n Bbkgi9UU/leK+V73+TM9UaL1IyEuQfvrSQKFQK1hH3Dy3NfbhBMNTl1n0EoLPc+UXdfb\n TRuw==","X-Gm-Message-State":"AOJu0Yw6lVJxddb7QB10R8RgQvwKcE1qBvw5U7P3Ay4UDGJAsoNlPw95\n jsTRloVuIJIfcEtlF+R4+GmstnwsMLgwVADlX3z4bOhCwD2NRdiPzpu65J8UyH6HLIefm7xbt3H\n HcyWAkvqhW1XFwZ0OTxfb/mjgZHK6Gvw=","X-Received":["by 2002:ac8:5c15:0:b0:417:974f:5619 with SMTP id\n i21-20020ac85c15000000b00417974f5619mr3925863qti.68.1695982223520;\n Fri, 29 Sep 2023 03:10:23 -0700 (PDT)","by 2002:ac8:5c15:0:b0:417:974f:5619 with SMTP id\n i21-20020ac85c15000000b00417974f5619mr3925848qti.68.1695982223218; Fri, 29\n Sep 2023 03:10:23 -0700 (PDT)"],"X-Google-Smtp-Source":"\n AGHT+IEMqtlgfRoQb+JKnv7VH1zy/ZAkYDdiQ+eTWqfyJRTVDSty4jVOK2Kw8mNQE4NmAP1E1wRtqpR6w/D31D0p0qU=","From":"Andrea Bolognani ","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>","MIME-Version":"1.0","In-Reply-To":"<20230926194951.183767-1-dbarboza@ventanamicro.com>","Date":"Fri, 29 Sep 2023 03:10:22 -0700","Message-ID":"\n ","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","To":"Daniel Henrique Barboza ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,\n palmer@rivosinc.com","Content-Type":"text/plain; charset=\"UTF-8\"","Received-SPF":"pass client-ip=170.10.133.124;\n envelope-from=abologna@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,\n 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.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190042,"web_url":"http://patchwork.ozlabs.org/comment/3190042/","msgid":"","list_archive_url":null,"date":"2023-09-29T10:46:30","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n> Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n> (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n> \n> Hi,\n> \n> These patches implements the base profile support for qemu-riscv and the\n> first profile, RVA22U64. \n> \n> As discussed in this thread [1] we're aiming for a flag that enables all\n> mandatory extensions of a profile. Optional extensions were left behind\n> and must be enabled by hand if desired. Since this is the first profile\n> we're adding, we'll need to add the base framework as well. \n> \n> The RVA22U64 profile was chosen because qemu-riscv implements all its\n> extensions, both mandatory and optional. That includes 'zicntr' and\n> 'zihpm', which we support for awhile but aren't adverting to userspace.\n> \n> Other design decisions made:\n> \n> - disabling a profile flag does nothing, i.e. we won't mass disable\n> mandatory extensions of the rva22U64 profile if the user sets\n> rva22u64=false;\n\nWhy shouldn't this be allowed ?\n\nIIUC, a profile is syntactic sugar for a group of features. If\nwe can disable individual features explicitly, why should we\nnot allow use of the profile as sugar to disable them en-mass ?\n\n\nBTW, I would caution that the semantics of mixing groups of\nfeatures, with individual features in -cpu is likely to be\nill defined, as you cannot rely on left-to-right processing\nof the -cpu arguments.\n\nIOW, if you say -cpu $foo,$group=on,$feature=off\n\nyou might expect this to result in '$feature' being disabled\nif it were implied by $group. This is not guaranteed as the\nQDict processing of options could result in us effectively\nprocessing -cpu $foo,$feature=off,$group=on\n\nThis brokeness with CPU feature groups and their interaction\nwith CPU feature flags already impacts s390x:\n\n https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg00981.html\n\nThere is a possible way to fix it by declaring an ordering\nsuch that all groups will be processed fully, before any\nindividual features are processed, and declaring that group\nor feature names must not be repeated. This avoids a reliance\non left-to-right ordering:\n\n https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg01005.html\n\nthat is still likely broken, however, if multiple different\ngroups are listed, and there is overlap in their feature\nsets.\n\nTL;DR: feature groups are pretty error prone if more than\none is listed by the user, or they're combined with individual\nfeatures.\n\n> \n> - profile support for vendor CPUs consists into checking if the CPU\n> happens to have the mandatory extensions required for it. In case it\n> doesn't we'll error out. This is done to follow the same prerogative\n> we always had of not allowing extensions being enabled for vendor\n> CPUs;\n\nWhy shouldn't this be allowed ?\n\n> - the KVM driver doesn't support profiles. In theory we could apply the\n> same logic as for the vendor CPUs, but KVM has a long way to go before\n> that becomes a factor. We'll revisit this decision when KVM is able to\n> support at least one profile.\n> \n> Patch 5 (\"enable profile support for vendor CPUs\") needs the following\n> series to be applied beforehand:\n> \n> \"[PATCH 0/2] riscv: add extension properties for all cpus\"\n> \n> Otherwise we won't be able to add the profile flag to vendor CPUs.\n> \n> [1] https://lore.kernel.org/qemu-riscv/35a847a1-2720-14ab-61b0-c72d77d5f43b@ventanamicro.com/\n> \n> Daniel Henrique Barboza (6):\n> target/riscv/cpu.c: add zicntr extension flag\n> target/riscv/cpu.c: add zihpm extension flag\n> target/riscv: add rva22u64 profile definition\n> target/riscv/tcg: implement rva22u64 profile\n> target/riscv/tcg-cpu.c: enable profile support for vendor CPUs\n> target/riscv/kvm: add 'rva22u64' flag as unavailable\n> \n> target/riscv/cpu.c | 25 ++++++++++\n> target/riscv/cpu.h | 10 ++++\n> target/riscv/cpu_cfg.h | 2 +\n> target/riscv/kvm/kvm-cpu.c | 5 +-\n> target/riscv/tcg/tcg-cpu.c | 98 ++++++++++++++++++++++++++++++++++++++\n> 5 files changed, 139 insertions(+), 1 deletion(-)\n> \n> -- \n> 2.41.0\n> \n> \n\nWith regards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=fzZlKPRf;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RxnB26nY0z1yp8\n\tfor ; Fri, 29 Sep 2023 20:47:53 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmB1B-0004At-3J; Fri, 29 Sep 2023 06:46:45 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmB19-0004AW-9W\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 06:46:43 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmB17-0007HK-5M\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 06:46:43 -0400","from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com\n [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n us-mta-533-wGYc2Rd3OsGy08kdphQy7Q-1; Fri, 29 Sep 2023 06:46:35 -0400","from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com\n [10.11.54.3])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D5E94101A529;\n Fri, 29 Sep 2023 10:46:34 +0000 (UTC)","from redhat.com (unknown [10.42.28.43])\n by smtp.corp.redhat.com (Postfix) with ESMTPS id 9A7DD1004145;\n Fri, 29 Sep 2023 10:46:33 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1695984399;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:in-reply-to:in-reply-to: references:references;\n bh=NDXDyU0wVHX7Zo+IO6ndoLidUjfEibxMerlcU+TWVs4=;\n b=fzZlKPRfRFt1FauQ8HrbL91jGgTk6k+98xCOepIpT6KZkSAKl1KRwfKh2v2aqFyflgcVwa\n aSHm+Fvs4RTQtyAWFbf7VUEJJOIiy9fdPJcbG97aFYns2ClxVfmDQsf/ugZEcfaUzv2qyU\n 1lBA/3Vg2ewgKOHFoPZ+Vm0tAX1KLgc=","X-MC-Unique":"wGYc2Rd3OsGy08kdphQy7Q-1","Date":"Fri, 29 Sep 2023 11:46:30 +0100","From":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","To":"Daniel Henrique Barboza ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn,\n zhiwei_liu@linux.alibaba.com, palmer@rivosinc.com","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","Message-ID":"","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20230926194951.183767-1-dbarboza@ventanamicro.com>","User-Agent":"Mutt/2.2.9 (2022-11-12)","X-Scanned-By":"MIMEDefang 3.1 on 10.11.54.3","Received-SPF":"pass client-ip=170.10.129.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n 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.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190072,"web_url":"http://patchwork.ozlabs.org/comment/3190072/","msgid":"","list_archive_url":null,"date":"2023-09-29T11:29:08","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":85468,"url":"http://patchwork.ozlabs.org/api/people/85468/","name":"Daniel Henrique Barboza","email":"dbarboza@ventanamicro.com"},"content":"On 9/29/23 07:46, Daniel P. Berrangé wrote:\n> On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n>> Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n>> (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n>>\n>> Hi,\n>>\n>> These patches implements the base profile support for qemu-riscv and the\n>> first profile, RVA22U64.\n>>\n>> As discussed in this thread [1] we're aiming for a flag that enables all\n>> mandatory extensions of a profile. Optional extensions were left behind\n>> and must be enabled by hand if desired. Since this is the first profile\n>> we're adding, we'll need to add the base framework as well.\n>>\n>> The RVA22U64 profile was chosen because qemu-riscv implements all its\n>> extensions, both mandatory and optional. That includes 'zicntr' and\n>> 'zihpm', which we support for awhile but aren't adverting to userspace.\n>>\n>> Other design decisions made:\n>>\n>> - disabling a profile flag does nothing, i.e. we won't mass disable\n>> mandatory extensions of the rva22U64 profile if the user sets\n>> rva22u64=false;\n> \n> Why shouldn't this be allowed ?\n> \n> IIUC, a profile is syntactic sugar for a group of features. If\n> we can disable individual features explicitly, why should we\n> not allow use of the profile as sugar to disable them en-mass ?\n\nIn theory there's no harm in allowing mass disabling of extensions but, given\nit's a whole profile, we would end up disabling most/all CPU extensions and\nthe guest would do nothing.\n\nThere is a thread in the ML:\n\nhttps://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n\nWhere we discussed the possibility of having a minimal CPU extension set. We didn't\nreach a consensus because the definition of \"minimal CPU extension set\" vary between\nOSes (Linux requires IMAFD, FreeBSD might require something differ).\n\nAssuming we reach a consensus on what a minimal set is, we could allow disabling mass\nextensions via probile but keeping this minimal set, for example. At very least we\nshouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\nthe minimum set that I would assume for now.\n\n\n> \n> \n> BTW, I would caution that the semantics of mixing groups of\n> features, with individual features in -cpu is likely to be\n> ill defined, as you cannot rely on left-to-right processing\n> of the -cpu arguments.\n> \n> IOW, if you say -cpu $foo,$group=on,$feature=off\n> \n> you might expect this to result in '$feature' being disabled\n> if it were implied by $group. This is not guaranteed as the\n> QDict processing of options could result in us effectively\n> processing -cpu $foo,$feature=off,$group=on\n> \n> This brokeness with CPU feature groups and their interaction\n> with CPU feature flags already impacts s390x:\n> \n> https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg00981.html\n> \n> There is a possible way to fix it by declaring an ordering\n> such that all groups will be processed fully, before any\n> individual features are processed, and declaring that group\n> or feature names must not be repeated. This avoids a reliance\n> on left-to-right ordering:\n> \n> https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg01005.html\n> \n> that is still likely broken, however, if multiple different\n> groups are listed, and there is overlap in their feature\n> sets.\n\nJust read the discussion. I agree with restricting the command line flexibility\nto make things more consistent, but IIRC libvirt (and others) uses a lot of\ncommand line appending and restricting these use cases now will break stuff\nup. I recall pc64 domains using to add extra cpu/machine\nflags to the domain back in the day. Surely we can claim (I guess) that command\nline pass-through is unstable and users shouldn't expect extended support for\nit, but we all know that users will be less than pleased when their domains\nstart breaking because QEMU restricted the command line.\n\nAs for the current RISC-V case, one thing we can do is to postpone feature group\nprocessing to realize() time, since in that stage we're already done with the\ncommand line processing. We can make a sanity check between the feature group\nflags and error out if there's something off. That would make things a little\nless fragile that what they are, albeit I'm sure that there will be some cases\nthat will be left uncovered.\n\n> \n> TL;DR: feature groups are pretty error prone if more than\n> one is listed by the user, or they're combined with individual\n> features.\n> \n>>\n>> - profile support for vendor CPUs consists into checking if the CPU\n>> happens to have the mandatory extensions required for it. In case it\n>> doesn't we'll error out. This is done to follow the same prerogative\n>> we always had of not allowing extensions being enabled for vendor\n>> CPUs;\n> \n> Why shouldn't this be allowed ?\n\nThere's no technical reason to not allow it. The reason it's forbid is to be\ncloser to what the real hardware would do. E.g. the real hardware doesn't allow\nusers to enable Vector if the hardware doesn't support it. Vendor CPUs also has\na privileged spec restriction as well, so if a CPU is running in an older spec\nit can't enable extensions that were added later.\n\nIf vendor CPUs from x86 and others behave in a different way with feature enablement\nI'd like to hear about it. I can say that what RISC-V is doing in this regard is\nnot that far from what PowerPC does.\n \n\n\nThanks,\n\nDaniel\n\n> \n>> - the KVM driver doesn't support profiles. In theory we could apply the\n>> same logic as for the vendor CPUs, but KVM has a long way to go before\n>> that becomes a factor. We'll revisit this decision when KVM is able to\n>> support at least one profile.\n>>\n>> Patch 5 (\"enable profile support for vendor CPUs\") needs the following\n>> series to be applied beforehand:\n>>\n>> \"[PATCH 0/2] riscv: add extension properties for all cpus\"\n>>\n>> Otherwise we won't be able to add the profile flag to vendor CPUs.\n>>\n>> [1] https://lore.kernel.org/qemu-riscv/35a847a1-2720-14ab-61b0-c72d77d5f43b@ventanamicro.com/\n>>\n>> Daniel Henrique Barboza (6):\n>> target/riscv/cpu.c: add zicntr extension flag\n>> target/riscv/cpu.c: add zihpm extension flag\n>> target/riscv: add rva22u64 profile definition\n>> target/riscv/tcg: implement rva22u64 profile\n>> target/riscv/tcg-cpu.c: enable profile support for vendor CPUs\n>> target/riscv/kvm: add 'rva22u64' flag as unavailable\n>>\n>> target/riscv/cpu.c | 25 ++++++++++\n>> target/riscv/cpu.h | 10 ++++\n>> target/riscv/cpu_cfg.h | 2 +\n>> target/riscv/kvm/kvm-cpu.c | 5 +-\n>> target/riscv/tcg/tcg-cpu.c | 98 ++++++++++++++++++++++++++++++++++++++\n>> 5 files changed, 139 insertions(+), 1 deletion(-)\n>>\n>> -- \n>> 2.41.0\n>>\n>>\n> \n> With regards,\n> Daniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com\n header.a=rsa-sha256 header.s=google header.b=lfd0Gqwz;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Rxp6y5kkXz1yp8\n\tfor ; Fri, 29 Sep 2023 21:30:18 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmBgP-0001GD-DX; Fri, 29 Sep 2023 07:29:21 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmBgN-0001Fc-Dd\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 07:29:19 -0400","from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1qmBgJ-0001BF-3Q\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 07:29:17 -0400","by mail-pj1-x1029.google.com with SMTP id\n 98e67ed59e1d1-2776ca9adb7so6442063a91.1\n for ; Fri, 29 Sep 2023 04:29:14 -0700 (PDT)","from [192.168.68.107] ([177.94.15.124])\n by smtp.gmail.com with ESMTPSA id\n iq12-20020a17090afb4c00b00274262bcf8dsm1222700pjb.41.2023.09.29.04.29.10\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 29 Sep 2023 04:29:12 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ventanamicro.com; s=google; t=1695986953; x=1696591753; darn=nongnu.org;\n h=content-transfer-encoding:in-reply-to:from:references:cc:to\n :content-language:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=z2agJXzV0YAIg6OBb6DLDrY4ExbClLF+uqg1FrUBp3U=;\n b=lfd0GqwzPUMaKXEvQ57xQ3qe4/w4L9ws9HzyKFAwIvC+vghcZWlFMHcz08UJ1juk2N\n 5n60RLi/JFV6dlyN05JvATaTP/4xSsfkY6E19B+2FNLquxvq1p2ozqo6QzINL1o0nu0X\n Gt28UGQx+AnkoEA2n+Ljy6vluMxYNlNYyxmbNs2rwBp7hHhSrUFXirfOp3EOFBn0Y/u3\n /EQ0bQ/kQ3oR7eItyul0zJL69EPVd/g2t1UlDeFDqRc9GkU7TSFTyGknunMv0mPjjt3J\n pzFcwMZQoIUDOUBZTKoEZQfCqiHYnAeD3N/ILLAxg5j0miRDJQn9oER7OBQt9eMFzLJS\n mv8A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1695986953; x=1696591753;\n h=content-transfer-encoding:in-reply-to:from:references:cc:to\n :content-language:subject:user-agent:mime-version:date:message-id\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=z2agJXzV0YAIg6OBb6DLDrY4ExbClLF+uqg1FrUBp3U=;\n b=Geq7LSVA2/iuv+m1n/Q48XaXCYGtKGDvh0sL1Km2s/L7ri7f4tqE5ysVe6U9fNyE/W\n QMp6BTMQZkloNGiFFeBNeLvNRhnm5f/PHuGqvheJZBxWH+tuWh6mbiyEiZSSqmZ3O+1e\n ScV/BEqoifH9+Jx9V2Ucie04PWYehIQKCAXvXqU7fFnU8BlKXcFjNBGEP9jHkjf2+uVM\n Agq5HTuJEofxgiwMqbnom3IpIYu+l9saatbDprtVo95XWCuSq4+AFV0bRAtZELrU9k45\n iAIfPhN0thPELdphZCQ52zfG7TjV3sI/3Y0IoNCCUP6Hq1F1Lm+32AIuQt9/94Nikl1U\n +bWQ==","X-Gm-Message-State":"AOJu0Yw+hIjPDtBkXzfKxJ3H0tyfru7XbpWPvCAsBUCHsUlQ7T2Igcde\n ESZozEWpt/5BoFEpnevHWbtJwQ==","X-Google-Smtp-Source":"\n AGHT+IEI0tVCMa1u3Hi0EG+8JinqH9gnVKXUVuaWR6XyVy9EVL3Svc8ywP0qZMDOt8huBgCF7ObH5Q==","X-Received":"by 2002:a17:90b:ecb:b0:274:6cc9:ec6d with SMTP id\n gz11-20020a17090b0ecb00b002746cc9ec6dmr3594708pjb.44.1695986952806;\n Fri, 29 Sep 2023 04:29:12 -0700 (PDT)","Message-ID":"","Date":"Fri, 29 Sep 2023 08:29:08 -0300","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","Content-Language":"en-US","To":"=?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,\n palmer@rivosinc.com, Andrew Jones ","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n ","From":"Daniel Henrique Barboza ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","Received-SPF":"pass client-ip=2607:f8b0:4864:20::1029;\n envelope-from=dbarboza@ventanamicro.com; helo=mail-pj1-x1029.google.com","X-Spam_score_int":"-53","X-Spam_score":"-5.4","X-Spam_bar":"-----","X-Spam_report":"(-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.295,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n 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.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190094,"web_url":"http://patchwork.ozlabs.org/comment/3190094/","msgid":"","list_archive_url":null,"date":"2023-09-29T11:55:39","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Fri, Sep 29, 2023 at 08:29:08AM -0300, Daniel Henrique Barboza wrote:\n> \n> \n> On 9/29/23 07:46, Daniel P. Berrangé wrote:\n> > On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n> > > Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n> > > (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n> > > \n> > > Hi,\n> > > \n> > > These patches implements the base profile support for qemu-riscv and the\n> > > first profile, RVA22U64.\n> > > \n> > > As discussed in this thread [1] we're aiming for a flag that enables all\n> > > mandatory extensions of a profile. Optional extensions were left behind\n> > > and must be enabled by hand if desired. Since this is the first profile\n> > > we're adding, we'll need to add the base framework as well.\n> > > \n> > > The RVA22U64 profile was chosen because qemu-riscv implements all its\n> > > extensions, both mandatory and optional. That includes 'zicntr' and\n> > > 'zihpm', which we support for awhile but aren't adverting to userspace.\n> > > \n> > > Other design decisions made:\n> > > \n> > > - disabling a profile flag does nothing, i.e. we won't mass disable\n> > > mandatory extensions of the rva22U64 profile if the user sets\n> > > rva22u64=false;\n> > \n> > Why shouldn't this be allowed ?\n> > \n> > IIUC, a profile is syntactic sugar for a group of features. If\n> > we can disable individual features explicitly, why should we\n> > not allow use of the profile as sugar to disable them en-mass ?\n> \n> In theory there's no harm in allowing mass disabling of extensions but, given\n> it's a whole profile, we would end up disabling most/all CPU extensions and\n> the guest would do nothing.\n\nTrue, that is just user error though. They could disable a profile\nand then manually re-enable individual features, and thus get a\nworking system.\n\n> There is a thread in the ML:\n> \n> https://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n> \n> Where we discussed the possibility of having a minimal CPU extension set. We didn't\n> reach a consensus because the definition of \"minimal CPU extension set\" vary between\n> OSes (Linux requires IMAFD, FreeBSD might require something differ).\n> \n> Assuming we reach a consensus on what a minimal set is, we could allow disabling mass\n> extensions via probile but keeping this minimal set, for example. At very least we\n> shouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\n> the minimum set that I would assume for now.\n\nI'd probably just call that user error too. \n\n> > \n> > TL;DR: feature groups are pretty error prone if more than\n> > one is listed by the user, or they're combined with individual\n> > features.\n> > \n> > > \n> > > - profile support for vendor CPUs consists into checking if the CPU\n> > > happens to have the mandatory extensions required for it. In case it\n> > > doesn't we'll error out. This is done to follow the same prerogative\n> > > we always had of not allowing extensions being enabled for vendor\n> > > CPUs;\n> > \n> > Why shouldn't this be allowed ?\n> \n> There's no technical reason to not allow it. The reason it's forbid is to be\n> closer to what the real hardware would do. E.g. the real hardware doesn't allow\n> users to enable Vector if the hardware doesn't support it. Vendor CPUs also has\n> a privileged spec restriction as well, so if a CPU is running in an older spec\n> it can't enable extensions that were added later.\n\nReal hardware is constrained in not being able to invent arbitrary\nnew features on chip. Virtual machines are not constrained, so\nI don't think the inability of hardware todo this, is an especially\nstrong reason to limit software emulation.\n\nWhat I don't like about this, is that (IIUC) the '$profile=on' option\nnow has different semantics depending on what CPU it is used with.\n\nie using it with a vendor CPU, $profile=on becomes an assertion\nthat the vendor CPU contains all the features needed to satisfy\n$profile. It won't enable/disable anything, just check it is present.\n\nWith a non-vendor CPU, using $profile=on becomes a mechanism to force\nenable all the features needed to satisfy $profile, there is no\nmechanism to just check for presence.\n\nHaving two different semantics for the same syntax is generally considered\nbad design practice.\n\nThis points towards supporting a tri-state, not boolean. $profile=check\nfor validation only, and $profile=on for force enablement.\n\n\nWith regards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=cobvf9Ao;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Rxphj4NF5z1yp0\n\tfor ; Fri, 29 Sep 2023 21:56:05 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmC64-0007Y1-Vl; Fri, 29 Sep 2023 07:55:53 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmC64-0007Xm-2W\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 07:55:52 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmC60-0005r3-QW\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 07:55:51 -0400","from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com\n [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n us-mta-335-HUjb9LcGNz2zfIGrN8BLvg-1; Fri, 29 Sep 2023 07:55:44 -0400","from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com\n [10.11.54.7])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C70FC800888;\n Fri, 29 Sep 2023 11:55:43 +0000 (UTC)","from redhat.com (unknown [10.42.28.43])\n by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D8E414171CA;\n Fri, 29 Sep 2023 11:55:41 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1695988547;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=vSYhVITJkf9yB42IRQELutbkHUlyKeDb+jWuND+J1Xw=;\n b=cobvf9AoEfcdL6RzwqyAkENWAX4JGAzmq9CtmqQHPLv9ZBQESel/dC3EX4DEIYeA3dyX6Y\n 4an2jVmEKUVq25NVmAUAB+OZ3x3i8vdHGcnPceBtXS8rFAGH7vUV4rMVL3YUJ5SN4xVDme\n 2ygYUlSDIixT35bzOppnkWplLjiGKi4=","X-MC-Unique":"HUjb9LcGNz2zfIGrN8BLvg-1","Date":"Fri, 29 Sep 2023 12:55:39 +0100","From":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","To":"Daniel Henrique Barboza ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn,\n zhiwei_liu@linux.alibaba.com, palmer@rivosinc.com,\n Andrew Jones ","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","Message-ID":"","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n \n ","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","User-Agent":"Mutt/2.2.9 (2022-11-12)","X-Scanned-By":"MIMEDefang 3.1 on 10.11.54.7","Received-SPF":"pass client-ip=170.10.129.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n 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.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190129,"web_url":"http://patchwork.ozlabs.org/comment/3190129/","msgid":"","list_archive_url":null,"date":"2023-09-29T12:49:47","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":85468,"url":"http://patchwork.ozlabs.org/api/people/85468/","name":"Daniel Henrique Barboza","email":"dbarboza@ventanamicro.com"},"content":"On 9/29/23 08:55, Daniel P. Berrangé wrote:\n> On Fri, Sep 29, 2023 at 08:29:08AM -0300, Daniel Henrique Barboza wrote:\n>>\n>>\n>> On 9/29/23 07:46, Daniel P. Berrangé wrote:\n>>> On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n>>>> Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n>>>> (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n>>>>\n>>>> Hi,\n>>>>\n>>>> These patches implements the base profile support for qemu-riscv and the\n>>>> first profile, RVA22U64.\n>>>>\n>>>> As discussed in this thread [1] we're aiming for a flag that enables all\n>>>> mandatory extensions of a profile. Optional extensions were left behind\n>>>> and must be enabled by hand if desired. Since this is the first profile\n>>>> we're adding, we'll need to add the base framework as well.\n>>>>\n>>>> The RVA22U64 profile was chosen because qemu-riscv implements all its\n>>>> extensions, both mandatory and optional. That includes 'zicntr' and\n>>>> 'zihpm', which we support for awhile but aren't adverting to userspace.\n>>>>\n>>>> Other design decisions made:\n>>>>\n>>>> - disabling a profile flag does nothing, i.e. we won't mass disable\n>>>> mandatory extensions of the rva22U64 profile if the user sets\n>>>> rva22u64=false;\n>>>\n>>> Why shouldn't this be allowed ?\n>>>\n>>> IIUC, a profile is syntactic sugar for a group of features. If\n>>> we can disable individual features explicitly, why should we\n>>> not allow use of the profile as sugar to disable them en-mass ?\n>>\n>> In theory there's no harm in allowing mass disabling of extensions but, given\n>> it's a whole profile, we would end up disabling most/all CPU extensions and\n>> the guest would do nothing.\n> \n> True, that is just user error though. They could disable a profile\n> and then manually re-enable individual features, and thus get a\n> working system.\n> \n>> There is a thread in the ML:\n>>\n>> https://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n>>\n>> Where we discussed the possibility of having a minimal CPU extension set. We didn't\n>> reach a consensus because the definition of \"minimal CPU extension set\" vary between\n>> OSes (Linux requires IMAFD, FreeBSD might require something differ).\n>>\n>> Assuming we reach a consensus on what a minimal set is, we could allow disabling mass\n>> extensions via probile but keeping this minimal set, for example. At very least we\n>> shouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\n>> the minimum set that I would assume for now.\n> \n> I'd probably just call that user error too.\n> \n>>>\n>>> TL;DR: feature groups are pretty error prone if more than\n>>> one is listed by the user, or they're combined with individual\n>>> features.\n>>>\n>>>>\n>>>> - profile support for vendor CPUs consists into checking if the CPU\n>>>> happens to have the mandatory extensions required for it. In case it\n>>>> doesn't we'll error out. This is done to follow the same prerogative\n>>>> we always had of not allowing extensions being enabled for vendor\n>>>> CPUs;\n>>>\n>>> Why shouldn't this be allowed ?\n>>\n>> There's no technical reason to not allow it. The reason it's forbid is to be\n>> closer to what the real hardware would do. E.g. the real hardware doesn't allow\n>> users to enable Vector if the hardware doesn't support it. Vendor CPUs also has\n>> a privileged spec restriction as well, so if a CPU is running in an older spec\n>> it can't enable extensions that were added later.\n> \n> Real hardware is constrained in not being able to invent arbitrary\n> new features on chip. Virtual machines are not constrained, so\n> I don't think the inability of hardware todo this, is an especially\n> strong reason to limit software emulation.\n> \n> What I don't like about this, is that (IIUC) the '$profile=on' option\n> now has different semantics depending on what CPU it is used with.\n> \n> ie using it with a vendor CPU, $profile=on becomes an assertion\n> that the vendor CPU contains all the features needed to satisfy\n> $profile. It won't enable/disable anything, just check it is present.\n> \n> With a non-vendor CPU, using $profile=on becomes a mechanism to force\n> enable all the features needed to satisfy $profile, there is no\n> mechanism to just check for presence.\n> \n> Having two different semantics for the same syntax is generally considered\n> bad design practice.\n> \n> This points towards supporting a tri-state, not boolean. $profile=check\n> for validation only, and $profile=on for force enablement.\n\nThis would leave us with:\n\n- $profile=off => disable all extensions. Let users hit themselves in the foot if they\ndon't enable any other extensions. Note that disabling a profile and enabling extensions\non top of it is very sensitive to left-to-right ordering, so it would be good to have\na way to enforce this ordering somehow (feature groups always first);\n\n- $profile=on => only valid for generic CPUs;\n\n- $profile=check -> valid for all CPUs, would only check if the CPU implements the profile.\n\n\nI think this is fine. Drew, care to weight in?\n\n\nThanks,\n\nDaniel\n\n> \n> \n> With regards,\n> Daniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com\n header.a=rsa-sha256 header.s=google header.b=iwa42LE7;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Rxqvy3JDHz1ypT\n\tfor ; Fri, 29 Sep 2023 22:50:54 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmCwm-0005A7-Bb; Fri, 29 Sep 2023 08:50:20 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmCwg-00058y-2o\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 08:50:15 -0400","from mail-oa1-x2d.google.com ([2001:4860:4864:20::2d])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1qmCwX-0007mM-NP\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 08:50:13 -0400","by mail-oa1-x2d.google.com with SMTP id\n 586e51a60fabf-1bba7717d3bso7122738fac.1\n for ; Fri, 29 Sep 2023 05:49:52 -0700 (PDT)","from ?IPV6:2804:7f0:bcc0:bdf2:b7ba:a476:c0e3:fb59?\n ([2804:7f0:bcc0:bdf2:b7ba:a476:c0e3:fb59])\n by smtp.gmail.com with ESMTPSA id\n f20-20020a63f114000000b005703a63836esm14528773pgi.57.2023.09.29.05.49.49\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 29 Sep 2023 05:49:51 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ventanamicro.com; s=google; t=1695991792; x=1696596592; darn=nongnu.org;\n h=content-transfer-encoding:in-reply-to:from:references:cc:to\n :content-language:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=psCRpBq/U9OjlmcAxothpQw4UR6vRHZJkLtoK0d2TMs=;\n b=iwa42LE7XcA5FGuWHP+Yljs0EkxUy0o6vILTnZXeR5js9zZybVhTsuoyJkxiUEGE5r\n qcerrjwNCNadCMIwmp1v2Qhm+WDRfurPAbAacA+NUwAqdOQDfjoFchfsWMFLpfkln+e7\n Rcib/hOMybDnXnCfWwoQoM8/4aIqFEVxawXfoQ34Jk4KAkLG6S1qrN05P/KKLRtPjMig\n muRUGtT6HB1AvHZ4Crqw7+70kPJLtYghnbZQLVyLJ8bKrhEJwB3Py/5cAVX1y2Gz3QX/\n D64ppxGIgRX8gaiVYBpRfpSuAR4KFhm1ncE4gxgccjFtYNp9Sc7wHW3zCaAyOeNVmcdM\n skxA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1695991792; x=1696596592;\n h=content-transfer-encoding:in-reply-to:from:references:cc:to\n :content-language:subject:user-agent:mime-version:date:message-id\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=psCRpBq/U9OjlmcAxothpQw4UR6vRHZJkLtoK0d2TMs=;\n b=aDyJyl+cQhTUbVKOIrksaTc3l+sERRNe79ut3678yhL97TMx8yxpF3VtK0K6gQzmYU\n OuuRzyucPXX2NkyPk4JeCLQaw8UzPQG461AUXo2xSszKc73adhuWBSZut4SsBNC7/t6I\n 2oSJWuUT4ysjA3HdJrCwEffmGFMz3WLHHAtFadP+qpl2Xx33Y2mvfGVIhMlXGhzrzpke\n NxS3U6Ra6pljffRvf+uJlpUE80ShI4um39Xd5/SgEVI3XPEiVCFMlglaU5grRhEmOnIS\n gaZ8H0+ycSJXSecNEU19ljiLawYTa/P+MsnxgDTG6q8gzznwWQQ3K42JBN6CoifnVqH+\n WwTA==","X-Gm-Message-State":"AOJu0YwilgEl86hT983oLp7MH5VhhWNvZ6d0xXJGubomD3BvmHiNoCu3\n zlCqCHKBTvejuN6mJBaTfzxP3IlCDyVuwYVQ8E8=","X-Google-Smtp-Source":"\n AGHT+IEUuF3vneqGwlkTp7Rqa8dJAKaDIFx/BJA6rcbUi1Jw5DonAxCOUnWRqwAvveLqyVJo9bR96w==","X-Received":"by 2002:a05:6870:14d0:b0:1d1:3c89:a7e5 with SMTP id\n l16-20020a05687014d000b001d13c89a7e5mr4361722oab.51.1695991791682;\n Fri, 29 Sep 2023 05:49:51 -0700 (PDT)","Message-ID":"","Date":"Fri, 29 Sep 2023 09:49:47 -0300","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","Content-Language":"en-US","To":"=?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,\n palmer@rivosinc.com, Andrew Jones ","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n \n \n ","From":"Daniel Henrique Barboza ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","Received-SPF":"pass client-ip=2001:4860:4864:20::2d;\n envelope-from=dbarboza@ventanamicro.com; helo=mail-oa1-x2d.google.com","X-Spam_score_int":"-53","X-Spam_score":"-5.4","X-Spam_bar":"-----","X-Spam_report":"(-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.295,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n T_SPF_TEMPERROR=0.01 autolearn=unavailable autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190132,"web_url":"http://patchwork.ozlabs.org/comment/3190132/","msgid":"","list_archive_url":null,"date":"2023-09-29T12:52:56","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Fri, Sep 29, 2023 at 09:49:47AM -0300, Daniel Henrique Barboza wrote:\n> \n> \n> On 9/29/23 08:55, Daniel P. Berrangé wrote:\n> > On Fri, Sep 29, 2023 at 08:29:08AM -0300, Daniel Henrique Barboza wrote:\n> > > \n> > > \n> > > On 9/29/23 07:46, Daniel P. Berrangé wrote:\n> > > > On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n> > > > > Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n> > > > > (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n> > > > > \n> > > > > Hi,\n> > > > > \n> > > > > These patches implements the base profile support for qemu-riscv and the\n> > > > > first profile, RVA22U64.\n> > > > > \n> > > > > As discussed in this thread [1] we're aiming for a flag that enables all\n> > > > > mandatory extensions of a profile. Optional extensions were left behind\n> > > > > and must be enabled by hand if desired. Since this is the first profile\n> > > > > we're adding, we'll need to add the base framework as well.\n> > > > > \n> > > > > The RVA22U64 profile was chosen because qemu-riscv implements all its\n> > > > > extensions, both mandatory and optional. That includes 'zicntr' and\n> > > > > 'zihpm', which we support for awhile but aren't adverting to userspace.\n> > > > > \n> > > > > Other design decisions made:\n> > > > > \n> > > > > - disabling a profile flag does nothing, i.e. we won't mass disable\n> > > > > mandatory extensions of the rva22U64 profile if the user sets\n> > > > > rva22u64=false;\n> > > > \n> > > > Why shouldn't this be allowed ?\n> > > > \n> > > > IIUC, a profile is syntactic sugar for a group of features. If\n> > > > we can disable individual features explicitly, why should we\n> > > > not allow use of the profile as sugar to disable them en-mass ?\n> > > \n> > > In theory there's no harm in allowing mass disabling of extensions but, given\n> > > it's a whole profile, we would end up disabling most/all CPU extensions and\n> > > the guest would do nothing.\n> > \n> > True, that is just user error though. They could disable a profile\n> > and then manually re-enable individual features, and thus get a\n> > working system.\n> > \n> > > There is a thread in the ML:\n> > > \n> > > https://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n> > > \n> > > Where we discussed the possibility of having a minimal CPU extension set. We didn't\n> > > reach a consensus because the definition of \"minimal CPU extension set\" vary between\n> > > OSes (Linux requires IMAFD, FreeBSD might require something differ).\n> > > \n> > > Assuming we reach a consensus on what a minimal set is, we could allow disabling mass\n> > > extensions via probile but keeping this minimal set, for example. At very least we\n> > > shouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\n> > > the minimum set that I would assume for now.\n> > \n> > I'd probably just call that user error too.\n> > \n> > > > \n> > > > TL;DR: feature groups are pretty error prone if more than\n> > > > one is listed by the user, or they're combined with individual\n> > > > features.\n> > > > \n> > > > > \n> > > > > - profile support for vendor CPUs consists into checking if the CPU\n> > > > > happens to have the mandatory extensions required for it. In case it\n> > > > > doesn't we'll error out. This is done to follow the same prerogative\n> > > > > we always had of not allowing extensions being enabled for vendor\n> > > > > CPUs;\n> > > > \n> > > > Why shouldn't this be allowed ?\n> > > \n> > > There's no technical reason to not allow it. The reason it's forbid is to be\n> > > closer to what the real hardware would do. E.g. the real hardware doesn't allow\n> > > users to enable Vector if the hardware doesn't support it. Vendor CPUs also has\n> > > a privileged spec restriction as well, so if a CPU is running in an older spec\n> > > it can't enable extensions that were added later.\n> > \n> > Real hardware is constrained in not being able to invent arbitrary\n> > new features on chip. Virtual machines are not constrained, so\n> > I don't think the inability of hardware todo this, is an especially\n> > strong reason to limit software emulation.\n> > \n> > What I don't like about this, is that (IIUC) the '$profile=on' option\n> > now has different semantics depending on what CPU it is used with.\n> > \n> > ie using it with a vendor CPU, $profile=on becomes an assertion\n> > that the vendor CPU contains all the features needed to satisfy\n> > $profile. It won't enable/disable anything, just check it is present.\n> > \n> > With a non-vendor CPU, using $profile=on becomes a mechanism to force\n> > enable all the features needed to satisfy $profile, there is no\n> > mechanism to just check for presence.\n> > \n> > Having two different semantics for the same syntax is generally considered\n> > bad design practice.\n> > \n> > This points towards supporting a tri-state, not boolean. $profile=check\n> > for validation only, and $profile=on for force enablement.\n> \n> This would leave us with:\n> \n> - $profile=off => disable all extensions. Let users hit themselves in the foot if they\n> don't enable any other extensions. Note that disabling a profile and enabling extensions\n> on top of it is very sensitive to left-to-right ordering, so it would be good to have\n> a way to enforce this ordering somehow (feature groups always first);\n\nIt is also order sensitive if 2 profiles have overlap in the\nextensions they represent. So might also require an ordering\nof profiles themselves to be defined if you permit multiple\nprofiles.\n\nIf we dont want to think about this immediately that, then\nwe should make $profile=off into a fatal error rather than\nsilently ignoring it\n\n> - $profile=on => only valid for generic CPUs;\n> \n> - $profile=check -> valid for all CPUs, would only check if the CPU implements the profile.\n> \n> \n> I think this is fine. Drew, care to weight in?\n\n\nWith regards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=B2PYmwYD;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RxqzS0HJ8z1yng\n\tfor ; Fri, 29 Sep 2023 22:53:56 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmCzW-00087x-6c; Fri, 29 Sep 2023 08:53:10 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmCzU-00083t-S7\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 08:53:08 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmCzS-00008v-Dw\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 08:53:08 -0400","from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com\n [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n us-mta-35-WAOjiUCVNK2NAMyYu4jxBg-1; Fri, 29 Sep 2023 08:53:01 -0400","from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com\n [10.11.54.8])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D18D285A5BE;\n Fri, 29 Sep 2023 12:53:00 +0000 (UTC)","from redhat.com (unknown [10.42.28.43])\n by smtp.corp.redhat.com (Postfix) with ESMTPS id 0D919C15BB8;\n Fri, 29 Sep 2023 12:52:58 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1695991985;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=MT9cqgfzf3xhZcdmenckS6KRLPsTP1yKIWmBcLnMies=;\n b=B2PYmwYDuB60LdBovLJyrpZY0dzvD9eWgHYkHK3nLIfDoQ3dAsyMdAkIpbf3rge+TZSncE\n 2BHYClzJV1JoE99tHBeqJRfZH5KizzGtbHiffRai8NKm7LBwf1CqMK2Q1eZPJmEGFVTKYK\n 5zUnBrTfYpnFOUnuXHdTNY/jUqxYKBk=","X-MC-Unique":"WAOjiUCVNK2NAMyYu4jxBg-1","Date":"Fri, 29 Sep 2023 13:52:56 +0100","From":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","To":"Daniel Henrique Barboza ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn,\n zhiwei_liu@linux.alibaba.com, palmer@rivosinc.com,\n Andrew Jones ","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","Message-ID":"","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n \n \n \n ","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","User-Agent":"Mutt/2.2.9 (2022-11-12)","X-Scanned-By":"MIMEDefang 3.1 on 10.11.54.8","Received-SPF":"pass client-ip=170.10.129.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n 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.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190154,"web_url":"http://patchwork.ozlabs.org/comment/3190154/","msgid":"<2acdbc24-33e6-3cd2-b4c7-713844f8211d@ventanamicro.com>","list_archive_url":null,"date":"2023-09-29T13:26:08","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":85468,"url":"http://patchwork.ozlabs.org/api/people/85468/","name":"Daniel Henrique Barboza","email":"dbarboza@ventanamicro.com"},"content":"On 9/29/23 09:52, Daniel P. Berrangé wrote:\n> On Fri, Sep 29, 2023 at 09:49:47AM -0300, Daniel Henrique Barboza wrote:\n>>\n>>\n>> On 9/29/23 08:55, Daniel P. Berrangé wrote:\n>>> On Fri, Sep 29, 2023 at 08:29:08AM -0300, Daniel Henrique Barboza wrote:\n>>>>\n>>>>\n>>>> On 9/29/23 07:46, Daniel P. Berrangé wrote:\n>>>>> On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n>>>>>> Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n>>>>>> (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n>>>>>>\n>>>>>> Hi,\n>>>>>>\n>>>>>> These patches implements the base profile support for qemu-riscv and the\n>>>>>> first profile, RVA22U64.\n>>>>>>\n>>>>>> As discussed in this thread [1] we're aiming for a flag that enables all\n>>>>>> mandatory extensions of a profile. Optional extensions were left behind\n>>>>>> and must be enabled by hand if desired. Since this is the first profile\n>>>>>> we're adding, we'll need to add the base framework as well.\n>>>>>>\n>>>>>> The RVA22U64 profile was chosen because qemu-riscv implements all its\n>>>>>> extensions, both mandatory and optional. That includes 'zicntr' and\n>>>>>> 'zihpm', which we support for awhile but aren't adverting to userspace.\n>>>>>>\n>>>>>> Other design decisions made:\n>>>>>>\n>>>>>> - disabling a profile flag does nothing, i.e. we won't mass disable\n>>>>>> mandatory extensions of the rva22U64 profile if the user sets\n>>>>>> rva22u64=false;\n>>>>>\n>>>>> Why shouldn't this be allowed ?\n>>>>>\n>>>>> IIUC, a profile is syntactic sugar for a group of features. If\n>>>>> we can disable individual features explicitly, why should we\n>>>>> not allow use of the profile as sugar to disable them en-mass ?\n>>>>\n>>>> In theory there's no harm in allowing mass disabling of extensions but, given\n>>>> it's a whole profile, we would end up disabling most/all CPU extensions and\n>>>> the guest would do nothing.\n>>>\n>>> True, that is just user error though. They could disable a profile\n>>> and then manually re-enable individual features, and thus get a\n>>> working system.\n>>>\n>>>> There is a thread in the ML:\n>>>>\n>>>> https://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n>>>>\n>>>> Where we discussed the possibility of having a minimal CPU extension set. We didn't\n>>>> reach a consensus because the definition of \"minimal CPU extension set\" vary between\n>>>> OSes (Linux requires IMAFD, FreeBSD might require something differ).\n>>>>\n>>>> Assuming we reach a consensus on what a minimal set is, we could allow disabling mass\n>>>> extensions via probile but keeping this minimal set, for example. At very least we\n>>>> shouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\n>>>> the minimum set that I would assume for now.\n>>>\n>>> I'd probably just call that user error too.\n>>>\n>>>>>\n>>>>> TL;DR: feature groups are pretty error prone if more than\n>>>>> one is listed by the user, or they're combined with individual\n>>>>> features.\n>>>>>\n>>>>>>\n>>>>>> - profile support for vendor CPUs consists into checking if the CPU\n>>>>>> happens to have the mandatory extensions required for it. In case it\n>>>>>> doesn't we'll error out. This is done to follow the same prerogative\n>>>>>> we always had of not allowing extensions being enabled for vendor\n>>>>>> CPUs;\n>>>>>\n>>>>> Why shouldn't this be allowed ?\n>>>>\n>>>> There's no technical reason to not allow it. The reason it's forbid is to be\n>>>> closer to what the real hardware would do. E.g. the real hardware doesn't allow\n>>>> users to enable Vector if the hardware doesn't support it. Vendor CPUs also has\n>>>> a privileged spec restriction as well, so if a CPU is running in an older spec\n>>>> it can't enable extensions that were added later.\n>>>\n>>> Real hardware is constrained in not being able to invent arbitrary\n>>> new features on chip. Virtual machines are not constrained, so\n>>> I don't think the inability of hardware todo this, is an especially\n>>> strong reason to limit software emulation.\n>>>\n>>> What I don't like about this, is that (IIUC) the '$profile=on' option\n>>> now has different semantics depending on what CPU it is used with.\n>>>\n>>> ie using it with a vendor CPU, $profile=on becomes an assertion\n>>> that the vendor CPU contains all the features needed to satisfy\n>>> $profile. It won't enable/disable anything, just check it is present.\n>>>\n>>> With a non-vendor CPU, using $profile=on becomes a mechanism to force\n>>> enable all the features needed to satisfy $profile, there is no\n>>> mechanism to just check for presence.\n>>>\n>>> Having two different semantics for the same syntax is generally considered\n>>> bad design practice.\n>>>\n>>> This points towards supporting a tri-state, not boolean. $profile=check\n>>> for validation only, and $profile=on for force enablement.\n>>\n>> This would leave us with:\n>>\n>> - $profile=off => disable all extensions. Let users hit themselves in the foot if they\n>> don't enable any other extensions. Note that disabling a profile and enabling extensions\n>> on top of it is very sensitive to left-to-right ordering, so it would be good to have\n>> a way to enforce this ordering somehow (feature groups always first);\n> \n> It is also order sensitive if 2 profiles have overlap in the\n> extensions they represent. So might also require an ordering\n> of profiles themselves to be defined if you permit multiple\n> profiles.\n> \n> If we dont want to think about this immediately that, then\n> we should make $profile=off into a fatal error rather than\n> silently ignoring it\n\nI don't mind handling it right now, I just don't know how hehe\n\nI'll re-read the thread you sent earlier and see if there's something I missed. I got the\nimpression that we need your qom patch first.\n\n\nThanks,\n\nDaniel\n\n> \n>> - $profile=on => only valid for generic CPUs;\n>>\n>> - $profile=check -> valid for all CPUs, would only check if the CPU implements the profile.\n>>\n>>\n>> I think this is fine. Drew, care to weight in?\n> \n> \n> With regards,\n> Daniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com\n header.a=rsa-sha256 header.s=google header.b=M89GOU/L;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RxrkZ5qGzz1yp8\n\tfor ; Fri, 29 Sep 2023 23:27:50 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmDVe-0007F0-F1; Fri, 29 Sep 2023 09:26:22 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmDVZ-0007EC-Kw\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 09:26:18 -0400","from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1qmDVW-0000I6-DS\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 09:26:17 -0400","by mail-pl1-x62b.google.com with SMTP id\n d9443c01a7336-1bf6ea270b2so109362035ad.0\n for ; Fri, 29 Sep 2023 06:26:14 -0700 (PDT)","from ?IPV6:2804:7f0:bdcd:fb00:6501:2693:db52:c621?\n ([2804:7f0:bdcd:fb00:6501:2693:db52:c621])\n by smtp.gmail.com with ESMTPSA id\n jj19-20020a170903049300b001b9d7c8f44dsm7673576plb.182.2023.09.29.06.26.09\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 29 Sep 2023 06:26:12 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ventanamicro.com; s=google; t=1695993972; x=1696598772; darn=nongnu.org;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=2xTgKcyUe7GD8wTMncPLGUmiX4p3ErMSPHISdg03bDo=;\n b=M89GOU/LYDWqhWzUyKUQc1wDKcYgtA2Oeb+wML4+XYGr6mgI9yqoS6uj8ByxBd8afF\n VJ/vfQWogM2HgqzALSih+at0Qtkhv47MZz0mDqOVcyHi9ZmXnulNnq9t3+4veLD+sglh\n HEppQK7A2Ky0rDd3tZhWcJ8Dc9R0JJ4+PAoe28UzBG9ZpM4PnUAvdfVQf4ELQs6IRnnO\n msq84lpBie344dgx1ztrl4twIm16uHNp3K6uwu1VkjYR5ModzRivEZqNJYJoq5Bh9t+8\n 61kccDFsbh+oU7CjP9uqU6Wi5cd9RrNZoKuYwtNhu7n1zH7IcJYkUXI+VuxFIdsNUaCq\n vy+Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1695993972; x=1696598772;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;\n bh=2xTgKcyUe7GD8wTMncPLGUmiX4p3ErMSPHISdg03bDo=;\n b=Xim4sdZkd+W6Ja4zLIyhwmIuDWB2e6KpS7QQBegKTyf3kwDb3HE/NgRMvv8nsYc7Lu\n R2xOXwiQc8iwmT35rZ+OqRywgaT82PdOMfkQOizlMhleszfsXc1CSwJLqsUGGRYrMY6j\n b0vy6PNFxzLiBQInn5K/TMRH3eOpmUBpWm1Q+xKoD2gxqHAzr7R6YiWNSvyQChmyfSxJ\n /X72RE12fxRlntrmvW9TGSoQovHzmcX8wiIjd50LyjXuum+DZ/+UMsDn9m69xXNalIvZ\n Vcq+S6rvwr3RBM0EqGOea032WIFC7wm9aX6HKBtsCIbkx4UpGJr3hadl01v4W7Te6q6F\n +GEg==","X-Gm-Message-State":"AOJu0YzobChy8golptmRZTKqjFxVjuz3XTS+vAj9KmiDXBUqTu2nVqj+\n 1zbXrt/8q9WicZMg40FrXFyn0Q==","X-Google-Smtp-Source":"\n AGHT+IEt9BHwc9RsUfQr3GeA25FurW3ISY1Nx31uJFT9Uq7+Ir7f4MFKM1se3aS+RS3g/B8PWJh1Bg==","X-Received":"by 2002:a17:903:25c2:b0:1c5:bb45:dd22 with SMTP id\n jc2-20020a17090325c200b001c5bb45dd22mr3672163plb.22.1695993972614;\n Fri, 29 Sep 2023 06:26:12 -0700 (PDT)","Message-ID":"<2acdbc24-33e6-3cd2-b4c7-713844f8211d@ventanamicro.com>","Date":"Fri, 29 Sep 2023 10:26:08 -0300","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","To":"=?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,\n palmer@rivosinc.com, Andrew Jones ","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n \n \n \n \n ","Content-Language":"en-US","From":"Daniel Henrique Barboza ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","Received-SPF":"pass client-ip=2607:f8b0:4864:20::62b;\n envelope-from=dbarboza@ventanamicro.com; helo=mail-pl1-x62b.google.com","X-Spam_score_int":"-53","X-Spam_score":"-5.4","X-Spam_bar":"-----","X-Spam_report":"(-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.295,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3190159,"web_url":"http://patchwork.ozlabs.org/comment/3190159/","msgid":"","list_archive_url":null,"date":"2023-09-29T13:32:14","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":2694,"url":"http://patchwork.ozlabs.org/api/people/2694/","name":"Daniel P. Berrangé","email":"berrange@redhat.com"},"content":"On Fri, Sep 29, 2023 at 10:26:08AM -0300, Daniel Henrique Barboza wrote:\n> \n> \n> On 9/29/23 09:52, Daniel P. Berrangé wrote:\n> > On Fri, Sep 29, 2023 at 09:49:47AM -0300, Daniel Henrique Barboza wrote:\n> > > \n> > > \n> > > On 9/29/23 08:55, Daniel P. Berrangé wrote:\n> > > > On Fri, Sep 29, 2023 at 08:29:08AM -0300, Daniel Henrique Barboza wrote:\n> > > > > \n> > > > > \n> > > > > On 9/29/23 07:46, Daniel P. Berrangé wrote:\n> > > > > > On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n> > > > > > > Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n> > > > > > > (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n> > > > > > > \n> > > > > > > Hi,\n> > > > > > > \n> > > > > > > These patches implements the base profile support for qemu-riscv and the\n> > > > > > > first profile, RVA22U64.\n> > > > > > > \n> > > > > > > As discussed in this thread [1] we're aiming for a flag that enables all\n> > > > > > > mandatory extensions of a profile. Optional extensions were left behind\n> > > > > > > and must be enabled by hand if desired. Since this is the first profile\n> > > > > > > we're adding, we'll need to add the base framework as well.\n> > > > > > > \n> > > > > > > The RVA22U64 profile was chosen because qemu-riscv implements all its\n> > > > > > > extensions, both mandatory and optional. That includes 'zicntr' and\n> > > > > > > 'zihpm', which we support for awhile but aren't adverting to userspace.\n> > > > > > > \n> > > > > > > Other design decisions made:\n> > > > > > > \n> > > > > > > - disabling a profile flag does nothing, i.e. we won't mass disable\n> > > > > > > mandatory extensions of the rva22U64 profile if the user sets\n> > > > > > > rva22u64=false;\n> > > > > > \n> > > > > > Why shouldn't this be allowed ?\n> > > > > > \n> > > > > > IIUC, a profile is syntactic sugar for a group of features. If\n> > > > > > we can disable individual features explicitly, why should we\n> > > > > > not allow use of the profile as sugar to disable them en-mass ?\n> > > > > \n> > > > > In theory there's no harm in allowing mass disabling of extensions but, given\n> > > > > it's a whole profile, we would end up disabling most/all CPU extensions and\n> > > > > the guest would do nothing.\n> > > > \n> > > > True, that is just user error though. They could disable a profile\n> > > > and then manually re-enable individual features, and thus get a\n> > > > working system.\n> > > > \n> > > > > There is a thread in the ML:\n> > > > > \n> > > > > https://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n> > > > > \n> > > > > Where we discussed the possibility of having a minimal CPU extension set. We didn't\n> > > > > reach a consensus because the definition of \"minimal CPU extension set\" vary between\n> > > > > OSes (Linux requires IMAFD, FreeBSD might require something differ).\n> > > > > \n> > > > > Assuming we reach a consensus on what a minimal set is, we could allow disabling mass\n> > > > > extensions via probile but keeping this minimal set, for example. At very least we\n> > > > > shouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\n> > > > > the minimum set that I would assume for now.\n> > > > \n> > > > I'd probably just call that user error too.\n> > > > \n> > > > > > \n> > > > > > TL;DR: feature groups are pretty error prone if more than\n> > > > > > one is listed by the user, or they're combined with individual\n> > > > > > features.\n> > > > > > \n> > > > > > > \n> > > > > > > - profile support for vendor CPUs consists into checking if the CPU\n> > > > > > > happens to have the mandatory extensions required for it. In case it\n> > > > > > > doesn't we'll error out. This is done to follow the same prerogative\n> > > > > > > we always had of not allowing extensions being enabled for vendor\n> > > > > > > CPUs;\n> > > > > > \n> > > > > > Why shouldn't this be allowed ?\n> > > > > \n> > > > > There's no technical reason to not allow it. The reason it's forbid is to be\n> > > > > closer to what the real hardware would do. E.g. the real hardware doesn't allow\n> > > > > users to enable Vector if the hardware doesn't support it. Vendor CPUs also has\n> > > > > a privileged spec restriction as well, so if a CPU is running in an older spec\n> > > > > it can't enable extensions that were added later.\n> > > > \n> > > > Real hardware is constrained in not being able to invent arbitrary\n> > > > new features on chip. Virtual machines are not constrained, so\n> > > > I don't think the inability of hardware todo this, is an especially\n> > > > strong reason to limit software emulation.\n> > > > \n> > > > What I don't like about this, is that (IIUC) the '$profile=on' option\n> > > > now has different semantics depending on what CPU it is used with.\n> > > > \n> > > > ie using it with a vendor CPU, $profile=on becomes an assertion\n> > > > that the vendor CPU contains all the features needed to satisfy\n> > > > $profile. It won't enable/disable anything, just check it is present.\n> > > > \n> > > > With a non-vendor CPU, using $profile=on becomes a mechanism to force\n> > > > enable all the features needed to satisfy $profile, there is no\n> > > > mechanism to just check for presence.\n> > > > \n> > > > Having two different semantics for the same syntax is generally considered\n> > > > bad design practice.\n> > > > \n> > > > This points towards supporting a tri-state, not boolean. $profile=check\n> > > > for validation only, and $profile=on for force enablement.\n> > > \n> > > This would leave us with:\n> > > \n> > > - $profile=off => disable all extensions. Let users hit themselves in the foot if they\n> > > don't enable any other extensions. Note that disabling a profile and enabling extensions\n> > > on top of it is very sensitive to left-to-right ordering, so it would be good to have\n> > > a way to enforce this ordering somehow (feature groups always first);\n> > \n> > It is also order sensitive if 2 profiles have overlap in the\n> > extensions they represent. So might also require an ordering\n> > of profiles themselves to be defined if you permit multiple\n> > profiles.\n> > \n> > If we dont want to think about this immediately that, then\n> > we should make $profile=off into a fatal error rather than\n> > silently ignoring it\n> \n> I don't mind handling it right now, I just don't know how hehe\n> \n> I'll re-read the thread you sent earlier and see if there's something I missed. I got the\n> impression that we need your qom patch first.\n\nMy patch is dropped as it was considered too gross. Kevin provided\na new impl for ARRAY properties which eliminates the ordering problem.\n\nIOW, QemuOpts iteration order will remain undefined in general.\n\nWith regards,\nDaniel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=L9G96Ipj;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Rxrrf5srKz1yp0\n\tfor ; Fri, 29 Sep 2023 23:33:06 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qmDbb-0002yB-5K; Fri, 29 Sep 2023 09:32:31 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmDba-0002xw-6g\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 09:32:30 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qmDbY-0001Yj-3i\n for qemu-devel@nongnu.org; Fri, 29 Sep 2023 09:32:29 -0400","from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73])\n by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n us-mta-623-04o6CL_FPsyQcRSudSsYdw-1; Fri, 29 Sep 2023 09:32:20 -0400","from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com\n [10.11.54.4])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A3F331C0514E;\n Fri, 29 Sep 2023 13:32:19 +0000 (UTC)","from redhat.com (unknown [10.42.28.43])\n by smtp.corp.redhat.com (Postfix) with ESMTPS id 031282026D68;\n Fri, 29 Sep 2023 13:32:16 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1695994346;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=v7Otf/rq0X29FCRiDiXGkFl4GHrPfZcsCx7n2iyDWwg=;\n b=L9G96Ipj2W/++sLwCwv+TxJH7J3WiH9Dx7gwCVUUC0UaUBL4prv5FpQRFT4dqazVvSxzEX\n XEwUxbnR5DZ2dIuzE5xVCCaW16XQBzJu6KdCncMLX/aVo1TiZrjIArhteu4baE+ZtYbMQq\n +ncp63Ms2JUTsk5ZSEphd2xu12wOuPo=","X-MC-Unique":"04o6CL_FPsyQcRSudSsYdw-1","Date":"Fri, 29 Sep 2023 14:32:14 +0100","From":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","To":"Daniel Henrique Barboza ","Cc":"qemu-devel@nongnu.org, qemu-riscv@nongnu.org, alistair.francis@wdc.com,\n bmeng@tinylab.org, liweiwei@iscas.ac.cn,\n zhiwei_liu@linux.alibaba.com, palmer@rivosinc.com,\n Andrew Jones ","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","Message-ID":"","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n \n \n \n \n \n <2acdbc24-33e6-3cd2-b4c7-713844f8211d@ventanamicro.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<2acdbc24-33e6-3cd2-b4c7-713844f8211d@ventanamicro.com>","User-Agent":"Mutt/2.2.9 (2022-11-12)","X-Scanned-By":"MIMEDefang 3.1 on 10.11.54.4","Received-SPF":"pass client-ip=170.10.129.124;\n envelope-from=berrange@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"12","X-Spam_score":"1.2","X-Spam_bar":"+","X-Spam_report":"(1.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=no autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Daniel =?utf-8?b?UC4gQmVycmFuZ8Op?= ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3195129,"web_url":"http://patchwork.ozlabs.org/comment/3195129/","msgid":"","list_archive_url":null,"date":"2023-10-09T02:32:47","subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","submitter":{"id":64571,"url":"http://patchwork.ozlabs.org/api/people/64571/","name":"Alistair Francis","email":"alistair23@gmail.com"},"content":"On Fri, Sep 29, 2023 at 10:54 PM Daniel P. Berrangé wrote:\n>\n> On Fri, Sep 29, 2023 at 09:49:47AM -0300, Daniel Henrique Barboza wrote:\n> >\n> >\n> > On 9/29/23 08:55, Daniel P. Berrangé wrote:\n> > > On Fri, Sep 29, 2023 at 08:29:08AM -0300, Daniel Henrique Barboza wrote:\n> > > >\n> > > >\n> > > > On 9/29/23 07:46, Daniel P. Berrangé wrote:\n> > > > > On Tue, Sep 26, 2023 at 04:49:44PM -0300, Daniel Henrique Barboza wrote:\n> > > > > > Based-on: 20230926183109.165878-1-dbarboza@ventanamicro.com\n> > > > > > (\"[PATCH 0/2] riscv: add extension properties for all cpus\")\n> > > > > >\n> > > > > > Hi,\n> > > > > >\n> > > > > > These patches implements the base profile support for qemu-riscv and the\n> > > > > > first profile, RVA22U64.\n> > > > > >\n> > > > > > As discussed in this thread [1] we're aiming for a flag that enables all\n> > > > > > mandatory extensions of a profile. Optional extensions were left behind\n> > > > > > and must be enabled by hand if desired. Since this is the first profile\n> > > > > > we're adding, we'll need to add the base framework as well.\n> > > > > >\n> > > > > > The RVA22U64 profile was chosen because qemu-riscv implements all its\n> > > > > > extensions, both mandatory and optional. That includes 'zicntr' and\n> > > > > > 'zihpm', which we support for awhile but aren't adverting to userspace.\n> > > > > >\n> > > > > > Other design decisions made:\n> > > > > >\n> > > > > > - disabling a profile flag does nothing, i.e. we won't mass disable\n> > > > > > mandatory extensions of the rva22U64 profile if the user sets\n> > > > > > rva22u64=false;\n> > > > >\n> > > > > Why shouldn't this be allowed ?\n> > > > >\n> > > > > IIUC, a profile is syntactic sugar for a group of features. If\n> > > > > we can disable individual features explicitly, why should we\n> > > > > not allow use of the profile as sugar to disable them en-mass ?\n> > > >\n> > > > In theory there's no harm in allowing mass disabling of extensions but, given\n> > > > it's a whole profile, we would end up disabling most/all CPU extensions and\n> > > > the guest would do nothing.\n> > >\n> > > True, that is just user error though. They could disable a profile\n> > > and then manually re-enable individual features, and thus get a\n> > > working system.\n> > >\n> > > > There is a thread in the ML:\n> > > >\n> > > > https://lore.kernel.org/qemu-riscv/CABJz62NyVNu4Z1qmCG7MyJkGG_9yWxjUFHHWjmoQEP6unRrHNA@mail.gmail.com/\n> > > >\n> > > > Where we discussed the possibility of having a minimal CPU extension set. We didn't\n> > > > reach a consensus because the definition of \"minimal CPU extension set\" vary between\n> > > > OSes (Linux requires IMAFD, FreeBSD might require something differ).\n> > > >\n> > > > Assuming we reach a consensus on what a minimal set is, we could allow disabling mass\n> > > > extensions via probile but keeping this minimal set, for example. At very least we\n> > > > shouldn't allow users to disable 'I' because that would kill the CPU, so RV64I is\n> > > > the minimum set that I would assume for now.\n> > >\n> > > I'd probably just call that user error too.\n> > >\n> > > > >\n> > > > > TL;DR: feature groups are pretty error prone if more than\n> > > > > one is listed by the user, or they're combined with individual\n> > > > > features.\n> > > > >\n> > > > > >\n> > > > > > - profile support for vendor CPUs consists into checking if the CPU\n> > > > > > happens to have the mandatory extensions required for it. In case it\n> > > > > > doesn't we'll error out. This is done to follow the same prerogative\n> > > > > > we always had of not allowing extensions being enabled for vendor\n> > > > > > CPUs;\n> > > > >\n> > > > > Why shouldn't this be allowed ?\n> > > >\n> > > > There's no technical reason to not allow it. The reason it's forbid is to be\n> > > > closer to what the real hardware would do. E.g. the real hardware doesn't allow\n> > > > users to enable Vector if the hardware doesn't support it. Vendor CPUs also has\n> > > > a privileged spec restriction as well, so if a CPU is running in an older spec\n> > > > it can't enable extensions that were added later.\n> > >\n> > > Real hardware is constrained in not being able to invent arbitrary\n> > > new features on chip. Virtual machines are not constrained, so\n> > > I don't think the inability of hardware todo this, is an especially\n> > > strong reason to limit software emulation.\n\nI think exposing flexibility in vendor CPUs just creates confusion.\n\nAs a user if I start QEMU with \"-cpu company-cpu\" then I am expecting\nto get an emulation of company-cpu.\n\n> > >\n> > > What I don't like about this, is that (IIUC) the '$profile=on' option\n> > > now has different semantics depending on what CPU it is used with.\n> > >\n> > > ie using it with a vendor CPU, $profile=on becomes an assertion\n> > > that the vendor CPU contains all the features needed to satisfy\n> > > $profile. It won't enable/disable anything, just check it is present.\n> > >\n> > > With a non-vendor CPU, using $profile=on becomes a mechanism to force\n> > > enable all the features needed to satisfy $profile, there is no\n> > > mechanism to just check for presence.\n> > >\n> > > Having two different semantics for the same syntax is generally considered\n> > > bad design practice.\n> > >\n> > > This points towards supporting a tri-state, not boolean. $profile=check\n> > > for validation only, and $profile=on for force enablement.\n> >\n> > This would leave us with:\n> >\n> > - $profile=off => disable all extensions. Let users hit themselves in the foot if they\n> > don't enable any other extensions. Note that disabling a profile and enabling extensions\n> > on top of it is very sensitive to left-to-right ordering, so it would be good to have\n> > a way to enforce this ordering somehow (feature groups always first);\n>\n> It is also order sensitive if 2 profiles have overlap in the\n> extensions they represent. So might also require an ordering\n> of profiles themselves to be defined if you permit multiple\n> profiles.\n>\n> If we dont want to think about this immediately that, then\n> we should make $profile=off into a fatal error rather than\n> silently ignoring it\n\nI think that makes sense.\n\nI think we can be pretty strict on profiles options. To me it seems\nreasonable to say a user can enable **one** profile. Once that profile\nis enabled they get all of those extensions.\n\nIf possible/simple we can then allow them to manually enable and/or\ndisable extensions on top of that. I don't see any use in allowing\nusers to turn profiles \"off\" though. I'm not even clear what that\nmeans.\n\nAlistair\n\n>\n> > - $profile=on => only valid for generic CPUs;\n> >\n> > - $profile=check -> valid for all CPUs, would only check if the CPU implements the profile.\n> >\n> >\n> > I think this is fine. Drew, care to weight in?\n>\n>\n> With regards,\n> Daniel\n> --\n> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|\n> |: https://libvirt.org -o- https://fstop138.berrange.com :|\n> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|\n>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20230601 header.b=PiBGIoEc;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S3jld2XJqz1yq7\n\tfor ; Mon, 9 Oct 2023 13:34:05 +1100 (AEDT)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1qpg5G-00086i-Qv; Sun, 08 Oct 2023 22:33:26 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1qpg5B-00086K-3D; Sun, 08 Oct 2023 22:33:21 -0400","from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1qpg57-0005cK-3A; Sun, 08 Oct 2023 22:33:20 -0400","by mail-vs1-xe2c.google.com with SMTP id\n ada2fe7eead31-4577c37392eso171285137.2;\n Sun, 08 Oct 2023 19:33:15 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20230601; t=1696818794; x=1697423594; darn=nongnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=U6BZPHpxBs8qgIIhZvatgKvhEGa0HTqWhIQeB99lFqI=;\n b=PiBGIoEc16CjVbMJTYt3E440+VD226TmIFe4FvWJkIJwd6GtEGr/jxzHNJNfpUtI6B\n xz2yUrKSc/7CDH0HYK6SREz3TutKILb8C7Zy1bPENdVG7n78YhxFBCufOF34rRWHsU8C\n OMnjWnnUQK6sNOwANhUxxUD/mA7r2fskNUUppnvfRpL1iq/LGdwlFAxMtvSit9wnErEd\n lZAIv+tdhXXq/nOPrCHV2cj6C8d8WScV7ul3yjclcIAUR/AGmKVme05BdG3cdvRj/kut\n FilmUBbmlGR98KyrCF7/TwB5nZIGN/seXD3Tg+XvmYlWsqy6R9tBqTzL6eIJi6f+JLF/\n gB0Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1696818794; x=1697423594;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=U6BZPHpxBs8qgIIhZvatgKvhEGa0HTqWhIQeB99lFqI=;\n b=O0UYJCYrfVVWor18l0ahGA+jU790wcGjx3u+PBOWZawbVvnrw9Uc0J4oSG4gU2Jfr7\n PqG+fb66EeonvebAi4kEDni+EMckCMgPph+KZ97jn7CVZt0MksuLDMHe9wnx8JFwDUge\n mwICTClv3pTB0sWTqUeYRoZBMwXj+Au/dOpAwwFFlRDaYR+NhLslZo5+3WPia8wtJN1n\n ZypCf3TKyzNSQoXGmGmi42GclAIL4xuOjQDVfWPrBw9vVsy8L7jHijxV3JeQ20Ln4cjf\n hl9ZW/crt0vJGRF7deNL2gsGBiulNUwIvBWahKjVfvuE5KDASEBop8UN10W61gX6Qybc\n UmPQ==","X-Gm-Message-State":"AOJu0Ywk5REQwmaqVzsmoQ+NfFGOBz4UFCyaHiuZS97tnn5zAyQ1I1pt\n jwq7soPFMFcnKBPJxXoWrjWZc2+6aLemfNoARkk=","X-Google-Smtp-Source":"\n AGHT+IGaZ0ABzWW3+Vkg40COkuO8LvzrmqYXON0JcK6K58zRsUKfMNo17JMi0xT83FjmV+3bjCjoPOGjC+CeL3FfvX4=","X-Received":"by 2002:a67:f117:0:b0:452:cfeb:1607 with SMTP id\n n23-20020a67f117000000b00452cfeb1607mr12566007vsk.5.1696818794536; Sun, 08\n Oct 2023 19:33:14 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194951.183767-1-dbarboza@ventanamicro.com>\n \n \n \n \n ","In-Reply-To":"","From":"Alistair Francis ","Date":"Mon, 9 Oct 2023 12:32:47 +1000","Message-ID":"\n ","Subject":"Re: [PATCH 0/6] riscv: RVA22U64 profile support","To":"=?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= ","Cc":"Daniel Henrique Barboza ,\n qemu-devel@nongnu.org,\n qemu-riscv@nongnu.org,\n alistair.francis@wdc.com, bmeng@tinylab.org, liweiwei@iscas.ac.cn,\n zhiwei_liu@linux.alibaba.com, palmer@rivosinc.com,\n Andrew Jones ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Received-SPF":"pass client-ip=2607:f8b0:4864:20::e2c;\n envelope-from=alistair23@gmail.com; helo=mail-vs1-xe2c.google.com","X-Spam_score_int":"-17","X-Spam_score":"-1.8","X-Spam_bar":"-","X-Spam_report":"(-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n 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.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]