From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F8AEC433FE for ; Wed, 23 Mar 2022 19:53:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9588A49F1C; Wed, 23 Mar 2022 15:53:22 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj0+f6-pMlS9; Wed, 23 Mar 2022 15:53:21 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 827BA49EEE; Wed, 23 Mar 2022 15:53:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4934B49EEE for ; Wed, 23 Mar 2022 15:53:20 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMVioCRI7339 for ; Wed, 23 Mar 2022 15:53:19 -0400 (EDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 39B6A49EED for ; Wed, 23 Mar 2022 15:53:19 -0400 (EDT) Received: by mail-io1-f50.google.com with SMTP id e22so3004320ioe.11 for ; Wed, 23 Mar 2022 12:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ey05sTiU2qlbU8kwj/4AtdgsovBnPHqmS42nG0aXPe4=; b=C2XX3ptmp7iD/+L38rLxHCKv+MC7cTKYynD9R0G3uf6eM4YjbyAcAwIKKKOS9Nm88f bkipYfhoLP1iaiyF07cmrsDtij8od+icgukWGgOIgW6V6KNE+6oC3iXxwWIiKZWKvrWv 3kVr1Uau4ONlunHm7FW+YwqMFgGRR/o1+/Vrcs2aJYbDXuUqMkjJEi35MBh6xSrDwEIQ 778SU1hchiQfPS/HEUuhYR1iA/ABf0VNQoVfg/emOUH0GQykvdLbv3sPlyLPruRHHicp ulgCKWw2Lmb5/Zu5M5staLb7/oEhxbk7LYIKpPpp9OtQNUot2GYewoUUoumCvNa0knWP c0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ey05sTiU2qlbU8kwj/4AtdgsovBnPHqmS42nG0aXPe4=; b=MFns+tamcXIyBSo+NOeMZGot9CdSsEJZe3z+BWaEYAJ+OTUxPXDqACApf/ilOqvE76 a9vAD23H9FUS14lhqeTjK+F6OR74SntkWLC/QmZd7JGj+AXM01iVet3eFx5AcRzxf2Rc /SZKV2wvyNfIwam9kZIT8FrkWbMNIVFRzF8/rq2TYM4p1Lkz2PV4GAXm2z7TP7ymqTvM glNC5KkiyJTJIu8jUO+mR8XBg4rWNJ/C0ySa3QnycgXaJU8YEZw9VV2kINHuxOdGH4Wx jpSM+LqHUbkGZ/Mh+NdUmcjyk1Eu1wz5hVTkA2ZsOxo3N5uifFI8HcddPyDk98JmdiZV 6YPw== X-Gm-Message-State: AOAM530qlDNASnJhTGWp5ckW/k7Xsp6rzUfpjNBVZFtgTXlls4GITFaH t2DWGlMFE8o3S/RxaSYpfsDuZw== X-Google-Smtp-Source: ABdhPJzUI0F5LFrmcE14GaFF3gmoKkkqu/VNMiQEZebQz2uN4fibQPYY9LvuU7HinRZJngUIkr4wZA== X-Received: by 2002:a05:6638:460d:b0:31a:7b70:e1b6 with SMTP id bw13-20020a056638460d00b0031a7b70e1b6mr797194jab.141.1648065198317; Wed, 23 Mar 2022 12:53:18 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id a3-20020a5ec303000000b006496b4dd21csm378009iok.5.2022.03.23.12.53.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 12:53:17 -0700 (PDT) Date: Wed, 23 Mar 2022 19:53:14 +0000 From: Oliver Upton To: Reiji Watanabe Subject: Re: [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-12-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220311044811.1980336-12-reijiw@google.com> Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Will Deacon , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Reiji, On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote: > Add hidden or reserved ID registers, and remaining ID registers, > which don't require special handling, to id_reg_desc_table. > Add 'flags' field to id_reg_desc, which is used to indicates hiddden > or reserved registers. Since now id_reg_desc_init() is called even > for hidden/reserved registers, change it to not do anything for them. > > Signed-off-by: Reiji Watanabe I think there is a very important detail of the series that probably should be highlighted. We are only allowing AArch64 feature registers to be configurable, right? AArch32 feature registers remain visible with their default values passed through to the guest. If you've already stated this as a precondition elsewhere then my apologies for the noise. I don't know if adding support for this to AArch32 registers is necessarily the right step forward, either. 32 bit support is working just fine and IMO its OK to limit new KVM features to AArch64-only so long as it doesn't break 32 bit support. Marc of course is the authority on that, though :-) If for any reason a guest uses a feature present in the AArch32 feature register but hidden from the AArch64 register, we could be in a particularly difficult position. Especially if we enabled traps based on the AArch64 value and UNDEF the guest. One hack we could do is skip trap configuration if AArch32 is visible at either EL1 or EL0, but that may not be the most elegant solution. Otherwise, if we are AArch64-only at every EL then the definition of the AArch32 feature registers is architecturally UNKNOWN, so we can dodge the problem altogether. What are your thoughts? -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7DA48C433EF for ; Wed, 23 Mar 2022 19:54:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=H7zCFYYOh6jVaPwgRvWVg8oZuT8+aiIAOpce1Wryk8g=; b=r/hNuS1lIVT3Av fRKw5gdVxr4hVchFwsDpO+q1gHCGcemtqH6Sn8z8ZXT/Qpi9Lc4H2PLIvOSYf5uRiohJzIEx/aJnN gqLEkFLSi26F2I4X5WURBteXs+Ylq22N1oBPTqsAEwygHJCuOR3PD3pfTvOEMRpJHt1IOd+ZWS4lB aQGuHuJ2vABhMyvb1461kc9ZjliQpcR7c2MaA2ydCGe2NbWJrgBa0t6/bSkVPv4gzEjQWb4UriMzN kf5i5kZlC2Kg9SdfAauwyrx3uAGpy8YZH5SLDBIg7zMsLGym+99/mRg835LtwfbT+6JD4rEqt65ih UMqFqLCv+MnV9ZURuDSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX72o-00El64-Nd; Wed, 23 Mar 2022 19:53:22 +0000 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX72l-00El5M-Ac for linux-arm-kernel@lists.infradead.org; Wed, 23 Mar 2022 19:53:20 +0000 Received: by mail-io1-xd32.google.com with SMTP id z6so3073905iot.0 for ; Wed, 23 Mar 2022 12:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ey05sTiU2qlbU8kwj/4AtdgsovBnPHqmS42nG0aXPe4=; b=C2XX3ptmp7iD/+L38rLxHCKv+MC7cTKYynD9R0G3uf6eM4YjbyAcAwIKKKOS9Nm88f bkipYfhoLP1iaiyF07cmrsDtij8od+icgukWGgOIgW6V6KNE+6oC3iXxwWIiKZWKvrWv 3kVr1Uau4ONlunHm7FW+YwqMFgGRR/o1+/Vrcs2aJYbDXuUqMkjJEi35MBh6xSrDwEIQ 778SU1hchiQfPS/HEUuhYR1iA/ABf0VNQoVfg/emOUH0GQykvdLbv3sPlyLPruRHHicp ulgCKWw2Lmb5/Zu5M5staLb7/oEhxbk7LYIKpPpp9OtQNUot2GYewoUUoumCvNa0knWP c0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ey05sTiU2qlbU8kwj/4AtdgsovBnPHqmS42nG0aXPe4=; b=yg0I2RxnucrOSZL1DM1GbdzCB+TM3qsn3freuJOx54CdG5KbBrv1aiMDbboy6iarfG 5kdA5iBYXwqxt5A+9ltzMq+IlPO74YL6cpAwnT+49QnLLU/+em10lnTpxtFOYtp3j37J dL6x9/Rvj7rr9xq38xZqXWoC39o6+4gunTpvLWmFY4kkBTMbhTDgPGws/ED/QMeDaZLw xho7LnVgltVOG2qVA8exPXmYuqpFENlosLwjlQ05JhuchVJnOB8vMJ7YFZoZqqUqxsAe hTLGZKZtXGSOciyNOF1CfTxxYOseUBsXu5XZ7oREVN/XBNr7UJ1wUASKOnbUtxD8dkTd LbFA== X-Gm-Message-State: AOAM531AX4QbtNXHgQfgYtTdIOhk1zuoLWajeyhmlHAVJHNdbzEhbkiy QaVWodFh6mkizWVAL9exgz/9/A== X-Google-Smtp-Source: ABdhPJzUI0F5LFrmcE14GaFF3gmoKkkqu/VNMiQEZebQz2uN4fibQPYY9LvuU7HinRZJngUIkr4wZA== X-Received: by 2002:a05:6638:460d:b0:31a:7b70:e1b6 with SMTP id bw13-20020a056638460d00b0031a7b70e1b6mr797194jab.141.1648065198317; Wed, 23 Mar 2022 12:53:18 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id a3-20020a5ec303000000b006496b4dd21csm378009iok.5.2022.03.23.12.53.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 12:53:17 -0700 (PDT) Date: Wed, 23 Mar 2022 19:53:14 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Fuad Tabba , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-12-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220311044811.1980336-12-reijiw@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220323_125319_393655_0390538F X-CRM114-Status: GOOD ( 16.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Reiji, On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote: > Add hidden or reserved ID registers, and remaining ID registers, > which don't require special handling, to id_reg_desc_table. > Add 'flags' field to id_reg_desc, which is used to indicates hiddden > or reserved registers. Since now id_reg_desc_init() is called even > for hidden/reserved registers, change it to not do anything for them. > > Signed-off-by: Reiji Watanabe I think there is a very important detail of the series that probably should be highlighted. We are only allowing AArch64 feature registers to be configurable, right? AArch32 feature registers remain visible with their default values passed through to the guest. If you've already stated this as a precondition elsewhere then my apologies for the noise. I don't know if adding support for this to AArch32 registers is necessarily the right step forward, either. 32 bit support is working just fine and IMO its OK to limit new KVM features to AArch64-only so long as it doesn't break 32 bit support. Marc of course is the authority on that, though :-) If for any reason a guest uses a feature present in the AArch32 feature register but hidden from the AArch64 register, we could be in a particularly difficult position. Especially if we enabled traps based on the AArch64 value and UNDEF the guest. One hack we could do is skip trap configuration if AArch32 is visible at either EL1 or EL0, but that may not be the most elegant solution. Otherwise, if we are AArch64-only at every EL then the definition of the AArch32 feature registers is architecturally UNKNOWN, so we can dodge the problem altogether. What are your thoughts? -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F1B0C433F5 for ; Wed, 23 Mar 2022 19:53:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240423AbiCWTyv (ORCPT ); Wed, 23 Mar 2022 15:54:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234227AbiCWTyt (ORCPT ); Wed, 23 Mar 2022 15:54:49 -0400 Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2533B7C16F for ; Wed, 23 Mar 2022 12:53:19 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id r2so3014211iod.9 for ; Wed, 23 Mar 2022 12:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ey05sTiU2qlbU8kwj/4AtdgsovBnPHqmS42nG0aXPe4=; b=C2XX3ptmp7iD/+L38rLxHCKv+MC7cTKYynD9R0G3uf6eM4YjbyAcAwIKKKOS9Nm88f bkipYfhoLP1iaiyF07cmrsDtij8od+icgukWGgOIgW6V6KNE+6oC3iXxwWIiKZWKvrWv 3kVr1Uau4ONlunHm7FW+YwqMFgGRR/o1+/Vrcs2aJYbDXuUqMkjJEi35MBh6xSrDwEIQ 778SU1hchiQfPS/HEUuhYR1iA/ABf0VNQoVfg/emOUH0GQykvdLbv3sPlyLPruRHHicp ulgCKWw2Lmb5/Zu5M5staLb7/oEhxbk7LYIKpPpp9OtQNUot2GYewoUUoumCvNa0knWP c0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ey05sTiU2qlbU8kwj/4AtdgsovBnPHqmS42nG0aXPe4=; b=KcLMR+ddS3aWOy3/p27hWyz8iwZeHkKh/u01JcZVtW9vhhpALjuqmvjGhXcBNjCYt4 CYZ+Y7GlT6ttDZDp16noj92Cp47G6WlKDxdP1ZpOWV4QMULoLG+YuAxZnmtHb523J8hK nd42yNAXjgcx9xZIhPKG9fJUH0/l0hgBXC7XATscBrc3t1Mx8XPT/G2iHaDKellDv9N7 0iRIbRuQKe0VlfGkGARDx178fewMLxz4IEfAfXZm/Few3dsD8DAr0ZZBlApjvaHPV33a 2ufD2QKVP8254z9u9u6iXbHndiDobJsEcG6/ckfkKH8gGiRuQ83/S56ErNGSsNGq3o/y KGJQ== X-Gm-Message-State: AOAM533y6X7E7X+0ST2MJtcSfMT0BVeP+i1IEsq9PUNIdrGpqLJ4FNNs ZzijUBoDZsUv2Z6yl3WCRgMztA== X-Google-Smtp-Source: ABdhPJzUI0F5LFrmcE14GaFF3gmoKkkqu/VNMiQEZebQz2uN4fibQPYY9LvuU7HinRZJngUIkr4wZA== X-Received: by 2002:a05:6638:460d:b0:31a:7b70:e1b6 with SMTP id bw13-20020a056638460d00b0031a7b70e1b6mr797194jab.141.1648065198317; Wed, 23 Mar 2022 12:53:18 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id a3-20020a5ec303000000b006496b4dd21csm378009iok.5.2022.03.23.12.53.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 12:53:17 -0700 (PDT) Date: Wed, 23 Mar 2022 19:53:14 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Fuad Tabba , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v6 11/25] KVM: arm64: Add remaining ID registers to id_reg_desc_table Message-ID: References: <20220311044811.1980336-1-reijiw@google.com> <20220311044811.1980336-12-reijiw@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220311044811.1980336-12-reijiw@google.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Reiji, On Thu, Mar 10, 2022 at 08:47:57PM -0800, Reiji Watanabe wrote: > Add hidden or reserved ID registers, and remaining ID registers, > which don't require special handling, to id_reg_desc_table. > Add 'flags' field to id_reg_desc, which is used to indicates hiddden > or reserved registers. Since now id_reg_desc_init() is called even > for hidden/reserved registers, change it to not do anything for them. > > Signed-off-by: Reiji Watanabe I think there is a very important detail of the series that probably should be highlighted. We are only allowing AArch64 feature registers to be configurable, right? AArch32 feature registers remain visible with their default values passed through to the guest. If you've already stated this as a precondition elsewhere then my apologies for the noise. I don't know if adding support for this to AArch32 registers is necessarily the right step forward, either. 32 bit support is working just fine and IMO its OK to limit new KVM features to AArch64-only so long as it doesn't break 32 bit support. Marc of course is the authority on that, though :-) If for any reason a guest uses a feature present in the AArch32 feature register but hidden from the AArch64 register, we could be in a particularly difficult position. Especially if we enabled traps based on the AArch64 value and UNDEF the guest. One hack we could do is skip trap configuration if AArch32 is visible at either EL1 or EL0, but that may not be the most elegant solution. Otherwise, if we are AArch64-only at every EL then the definition of the AArch32 feature registers is architecturally UNKNOWN, so we can dodge the problem altogether. What are your thoughts? -- Thanks, Oliver