Received: by 2002:ab2:1689:0:b0:1f7:5705:b850 with SMTP id d9csp1098585lqa; Sun, 28 Apr 2024 19:23:31 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWMWS8OfrXgnX1XmyiQPAh/tPNPD52s6gBaokTPc2bxMHO9R+Guf+kWUrlm4efaWSW3xfRrzVTxgIqQLiSQSl8Hys21ypuRIxbIgJFxnw== X-Google-Smtp-Source: AGHT+IEcWAhxZ4W7bMkm78vQtcmn7LobtrkQ+xBABU1czyjPXWFsXZOwyDke6LZqiOwHeS1vzhlb X-Received: by 2002:a50:8a92:0:b0:568:9d96:b2d1 with SMTP id j18-20020a508a92000000b005689d96b2d1mr3348733edj.32.1714357411257; Sun, 28 Apr 2024 19:23:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714357411; cv=pass; d=google.com; s=arc-20160816; b=po1USh4IejrjktzsdrMmLLcqq53ej8spcoctE2kitS624+bel3NWizna/Wz006oEg/ joSVuKtB+9IS6PfsSwTYWR3OoKf6O6g4A98ZyBZZOcQck2jNmoF899GrOTYLdGw3o31G 0p7njBbSxae8jjxtx9SCS4Wi2VYPKVcHbT0CFvyMGFr+EPmsxkn1X+NO/LUNMvbzjX13 qcAu8ZR8u1oTlkrUAtcnegGaGqGjJ7tBM9NOGdE9oxwn6gm7vevedgMxz+hblIQSMhwq Ga3HJ4m5PO0U03wmRW9EGz/+xejq06qiyz1oS3o9uRxHWQRM310tHd15RD3lGe7gLYJj EdEA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=Ba/+SUPnDah2rEstJ4oQB2b6+y8D3+GCAF/i7OUgzxE=; fh=Va2dQhqnMh0S5q4rhEpLyjP1YPvoow1QdNaEMWkDXr4=; b=x0WX0sLk5qd5EwpbQXk9kZolC3jczQSLknGQlbudN/GOTvirIeOrdRZY1S+2ICsifv biQI2Rg1N9HOsj5Jp1IICP8jOUJ6cYSrQH/NF3A0x+dWeaKDKPFH3QxQ3nUaB7RVlptC U49M+nZGFYTKTMrTNtDreMolfn1l53tt2StDGSQytkt15fKxRrxRPfc2zg6Jvr6s8yr3 qCjGRjIgCaY28NqfiX9pnkZCOO9NPJAy+/A6ZwhI45Q0QOAoc87ClaTilZ/UgE6/CPQq 6oHi5gBoJLjXseb9pwgZ7ufefcz4HL8FYn2Fpt7brgj3vbQOVYDNUeICesJuVROIJ1zP 4b+w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-161680-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-161680-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id a3-20020a05640233c300b0056e5c132f49si13799594edc.592.2024.04.28.19.23.31 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Apr 2024 19:23:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-161680-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-161680-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-161680-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CDBCF1F217FD for ; Mon, 29 Apr 2024 02:23:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7368A17FD; Mon, 29 Apr 2024 02:23:23 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4752C7EB for ; Mon, 29 Apr 2024 02:23:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714357403; cv=none; b=VWz+FI9xr6/ijy9xH5IUCUKx+aDgFbbSpNQnXsRZdl8S0IZoIB4f1JpEgZ00jyLeaJo6AxMs1dx7GLHGG6zwJvAwu9GjDWj4Pn2g9xvnvg4WEdDY/Bnu90kg9YXCIDsKgiRcVysNz0atjf1b9YaywoXFaXwRb9pIXe+OPZ0ZtVo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714357403; c=relaxed/simple; bh=FscvFKLev/pbFhBKOoUhHWN2J3QCiz+0dzat4SNZspg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qW0zFBIzVQKI17FvLp2KIEMACtaRX8zDteN1unGPA2GUq1VMGOJu+WCFMuXIcEaqvLbjj0n77ONjus3x/vxYGWLhYZn3vyW1ZpTfWQbIK+6OVNn0PyX/TNZGBRUolj9j/n4V4cAdR29++6NabIHOyn5OEZCrHon4O4wOexiijrU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A6C812F4; Sun, 28 Apr 2024 19:23:47 -0700 (PDT) Received: from [10.162.42.72] (a077893.blr.arm.com [10.162.42.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF2BF3F73F; Sun, 28 Apr 2024 19:23:17 -0700 (PDT) Message-ID: Date: Mon, 29 Apr 2024 07:53:14 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] KVM: arm64: Replace custom macros with fields from ID_AA64PFR0_EL1 Content-Language: en-US To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, Oliver Upton , Will Deacon , kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, Fuad Tabba References: <20240418053804.2573071-1-anshuman.khandual@arm.com> <20240418053804.2573071-2-anshuman.khandual@arm.com> <871q73rufi.wl-maz@kernel.org> From: Anshuman Khandual In-Reply-To: <871q73rufi.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/18/24 13:09, Marc Zyngier wrote: > + Fuad > > On Thu, 18 Apr 2024 06:38:03 +0100, > Anshuman Khandual wrote: >> >> This replaces custom macros usage (i.e ID_AA64PFR0_EL1_ELx_64BIT_ONLY and >> ID_AA64PFR0_EL1_ELx_32BIT_64BIT) and instead directly uses register fields >> from ID_AA64PFR0_EL1 sysreg definition. >> >> Cc: Marc Zyngier >> Cc: Oliver Upton >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: kvmarm@lists.linux.dev >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual >> --- >> arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 8 ++++---- >> arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++-- >> arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +- >> 3 files changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> index 51f043649146..0034bfffced6 100644 >> --- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> +++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> @@ -52,10 +52,10 @@ >> * Supported by KVM >> */ >> #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\ >> - FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \ >> - FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \ >> - FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \ >> - FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \ >> + FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_EL0_IMP) | \ >> + FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_EL1_IMP) | \ >> + FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_EL2_IMP) | \ >> + FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_EL3_IMP) | \ > > If you are going to rework this, can we instead use something less > verbose such as SYS_FIELD_GET()? Just wondering, is not FIELD_PREP() and SYS_FIELD_GET() does the exact opposite thing. The earlier builds the entire register value from various constituents, where as the later extracts a single register field from a complete register value instead. Or did I just misunderstood something here. > > There is also a series from Fuad moving things around, and maybe > that's the opportunity to rework this while limiting the amount of > cosmetic churn. Not to that this fixed config stuff needs to be I guess that might be a better place to change the code instead. Because this series just replaces the derived register field from tools syreg, but will be happy to have those changes here as well in a separate pre/post patch. > reworked in order to match the runtime feature enforcement that the > rest of KVM has adopted. I am afraid, did not get the above. Could you please give some more details.