From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.219.52 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793227406; b=OIC8fDetYWfJlK3/8jQmFFfCubbMAx3OtZGLGv1M/CfTVOvTvFVKp6hxUrwbycFUP/sm G6ALEUWM03Ok6wr+8XGBU76vZ8R3FgekdJ6Rsyk7EOSslT6coikKaGL59UerPV1jC5TZw tnPGPdl072ufl/DLQzeYzRUn0apIgaJPIgzblq0Dnb1ap7oqXxNzO9jt3HJUFxU+Ae/r+ ekjWkt4SZbideENOakAmKF9mgAzlS2Igd9ZqBAOYb7yJKbd48SOup+L0rHVb6IqXrk/YI ysOnhOAf4T84CdB40XjCytVR9ucEGleSOOmOMNriuCXHZhT4YJZ2z4dCko+fwxQ6udg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793227406; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Gm-Message-State:X-Gm-Gg:X-Received:Received:From:To:Cc:Subject: Date:Message-ID:X-Mailer:MIME-Version:Content-Transfer-Encoding; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=YfPqDsS9zLzOP4X+BXDmIUT/loAYuoVuAlqPY+ikrM8Pi3Fov2uhPSgozP+S1LG5rs16 IT1qzlT9wa0sXJYNJGdXkW2LM4x27adYzmeXqGKTFa+q1Cv4D6nHmwdeGmqD1rvKQF0XT UXfLDElzezZExXNxEWvY59cfmDfZUUJ9UjiN6mzYGEUo1EfvnU2S7rwCvDgNh+O6jwBW0 irDBue9jCZC6xYaVp4RkdDvmWkuh2cV8xrs3bhJmdbE1uzcd0Yd08ZQ2BEzdr/5fHIiyR So3eDO7xNTfp70EzAY3HBOknNC0dD0dhsmgAfxgZmbA3HWc8CdHtwTXmJbljbjaQ7kQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=lQp4S+Vq; arc=none smtp.remote-ip=209.85.219.52 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4661606A31C for ; Wed, 28 Oct 2026 22:43:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org D4661606A31C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=lQp4S+Vq Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-91791ec1b83so12602366d6.1 for ; Wed, 28 Oct 2026 15:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793227405; x=1793832205; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=lQp4S+VqbSlQwdzBwvFGFKLSCJ33FEcbI1/XWwziY202gcLj+wWke+uOTIsLXFcZEZ OgF+l4vw4UYlH6RpbYRfsqyTouyxsFPjHes0lycbvwj3HxE0UFQS8UQokqfwjsXub8fk AWevC0K4eg9MhctNn/xfll6H056bR2tWkwr1dKUP9Ms/AtLrCZdwBMtvToPp1kMYZ2uh o6uwv4sqkR665mDVdxrs2tNh5SJ8exG8q+xqo410R3uDb14KVPEFTU52sT0+/qqFvHCK kuUEYlU7KJhLVIcRL31RF80b+imUNo7+il5ClzD6V1b2QebCqGuLUX9KC8vm1HMF+n6/ T56Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793227405; x=1793832205; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=Wtb+GbeLBqqzPmpfPgR7UnVpA79bAhGDN2PtXNYzGu0eRyKuDEUgiUggE6j5j2n1OX yXDeo/GmIJCwuv/ylThVQDPENXjDSGfqd/ALL5a65NbZfhjLE1Uss5Q0w0LMoZqRwBY/ CFtZly6NA4C8+Z4jsJXqiD3LECesuNnJizkWA4+Pwj54R4R7WY1TT4PP5gGCgoT37mK1 VaNp2lIvHRlXIStuOho955yFDbOAJVJXDOdLuPTzNQQEEeMcL4XmtAD151blfYJv93R9 gR4OJJvDJJ9PpByFXVPQt18XzRIv4O1waMsV750cL+NCYtM7bJ72auvsln4sqCWb/3SO AfSg== X-Gm-Message-State: AFq9FYKap9nLwbcQaMRRkX546aHlPQ25+kHWLr/ACFK4oAFb6dlEPWFj JLcGgIQI3M3+J3Qe8qG8oAKxZDlHlDT8n+bqMkAMd8ZitDldcmcXhh1s X-Gm-Gg: AYBFou3LvUqXoaEC5Fpk0IwbTwIc2mGgRaGg8rVDcWbuUK3Z2hanJplYcNxsCDILU30 7nqIyfbRzEN0PhoiME2vuSWc1xCoak1sTc9WE07nnVIe4vIaRBm6k1CJEUDUExhsi/N1xZMc7d3 H4Lf2A/EwW1URNAFtFqVYun8XZU1h7Ssu6bIl2J7jdzWDQVR+kHBtHyo3/IER9WQnQtSorfRU7G P/bTgY14SDtUVmtjiWkByK0FdwYmWBzd8aFAzbpLafRsUUBqfQN9IeZ5GFbWCEvgbELVkIcyv35 B8paE/wqr433D9VuYl+jPGuEmrwlNA/3ocdm9Cdi8o2xUuulfiLyPNAmdshJ5Tiee2GPAY3XmVZ Q/kePE4eNwi2RdP/czkl+c64xhG/fSR8OkFXtBszbsQu4zrxL1GzN7L19jDv9edatMaokKItplB 2UJvTWliM/s8r5I38J/7rpGAmLwXqFok0uC2UDgUWFi4cKtsTjB4mpjAHrJbwLQASjkMx28tn04 nKfyTOEX0DN7QXbVLnHcruzlJVbpbTT8FZUJaHrv3UMOvtB+FTli97LFOf/9GhRpgR4g0cA2WW9 duBc2HhdbqSX9uGxWw9dXebnAWLNzIopTDlke+sGMc860oLjLDwecBzmhn7LDuZ/VmC0TDALifS XNTstWsAhZPtNhybsT8Wyvm70QP6e8N7155ov4iBXcR78df5yrpM= X-Received: by 2002:a05:620a:26a1:b0:93e:c12c:fbc8 with SMTP id af79cd13be357-94408d361damr565214385a.68.1793227404758; Wed, 28 Oct 2026 15:43:24 -0700 (PDT) Received: from paul-white-HP-Pavilion-Laptop-15-cs1xxx.mynetworksettings.com ([2600:4040:ad65:1c00:b8:5aeb:4bda:886]) by smtp.gmail.com with ESMTPSA id af79cd13be357-940f0787d96sm1370085685a.28.2026.10.28.15.43.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 15:43:24 -0700 (PDT) From: Paul White To: anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr Cc: kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Paul White Subject: [PATCH v2 0/2] KVM: riscv: Unify and optimize FP register loops Date: Wed, 28 Oct 2026 18:43:07 -0400 Message-ID: X-Mailer: git-send-email 2.53.0 X-Mailing-List: kvm@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The change to both patches in this series is a structural/architectural one. Both functions set_reg and get_reg use identical code to locate the register the application specified in the token even though they do different things with that location information: the set_reg function adds data the application requested to send to that identified location (in the copy_from_user function) while the get_reg function retrieves what data is at that identified location and sends it to the application (using the copy_to_user function). Everything else is the same. That is the only difference between the code. Therefore I was able to apply the same solution to both of the function's finding-the-requested-register parts (which is everything up until the final if statement) which were filled with redundancy. The solution I came up with is to create local variables for the entire function for all the variables of the original code that would be different, depending on the floating point type. Then once I ask whether it is a double floating point or single floating point mode, I assign the aforementioned variables to the values they should have for that mode so that when I go through the if statements that ask whether the requested register number is a status control register or data register, I only have to go through it once because the respective floating point values/addresses would have been assigned to the aforementioned local variables, so the whole code kind of changes or is tailored to the floating point type. This architectural change/solution will make the cpu execute the code faster (as the cpu will have less decisions to make and the bare-metal math used to figure out the address of the register is executed faster by the cpu than looking up object properties and array indexes), is more maintainable, and is more readable. --- v2: - Both patches had the same flawed line of code. The checking if the token's size was 32 or 64 bits line allowed token's with mismatched sizes & types to pass. I fixed this by checking it had the right size for its type by replacing the u32/u64 parts with a mode-dependent local variable, byte_offset. Paul White (2): KVM: riscv: Eliminate redundancy in get_reg function via pointers KVM: riscv: Eliminate redundancy in set_reg function via pointers arch/riscv/kvm/vcpu_fp.c | 124 +++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 52 deletions(-) -- 2.53.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58A2660A2620 for ; Wed, 28 Oct 2026 22:43:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=0Xp5Qm61; dkim=fail reason="signature verification failed" (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=kDiUv/LP 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:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Unsubscribe-Post:List-Owner; bh=ZXHMp9f51fa1LMWv0gBFHBlPIa26lynX06sia+vff3c=; b=0Xp5Qm610bHMJRbU/UQcoyBpN7 43mgK+qEKf4NqOLgXPd90BlSNHhjruk2CnYYINv3FTTrKgx7w8EPTfUcPZwqgLIbgmA+w+xq3JvbX VdPMG8FMgLh/lLu0e2z2OgC/ZtmT2aQUsgl0Iil9j6+E6HDj012hFyiITX44bckWCtlzHm9REBsLj mjTmFkvxjp0dQdI1zZdJK54+P8dK37SmbtCDLqSEQH/kSBzdNC2aaeS7hpJW/Ym3MgO1SaOjzkJgG Gy2P8/U10Rh9QvqT9fdsFA3+CjQ28wkta3tquUUC3yAi/iqDpSsDO3zNC7IOGE+5iC7GmI+MYP1jw T9BM3M9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xMCMj-000000081vj-2Lyi; Wed, 28 Oct 2026 22:43:29 +0000 Received: from mail-qk1-x736.google.com ([2607:f8b0:4864:20::736]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xMCMh-000000081tw-0CcW for kvm-riscv@lists.infradead.org; Wed, 28 Oct 2026 22:43:28 +0000 Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-93f36c18b75so81754585a.1 for ; Wed, 28 Oct 2026 15:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793227405; x=1793832205; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=kDiUv/LP4cjPX6FihPNtG7yUBj6MQ25DoW9cQnbObOcdLUsgh12kIp8IZv4JfWn+4z I9zGYEsRqyH8+1vUPQNSZ5Sc5bOVci6nyKUW2729O8cZU6Uv8LJkONU8ENQCrZwY81xy oPAuaN56wT22SGgN3oRpO+iJoAwxioC2fDndlbjHb5f7q37SfpBtrqG44Y9Xisr2BMge d1TEkLGphwuPbwPaEQcrCtlhrLFbAPO/RUNJX61QYxfD/sGnxx33ni1TprkQnODBnNn+ 9PF5leruduuizlU1pkdK+9DwTrXb34LFn299pbTL3EURQYOZQvp3WfaCPv6ndRBZcTnE ziIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793227405; x=1793832205; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=VEQJJH7YWbo8zG8+EzmJtHiOOjClz7saBW7t3k/BjmaEHbxRInk3pvicDIljz2sC6O 0VTfONBx4SJS3azh7dESC336sl3gWFtnSdd84X5qR3v9allTaaEzfH3bs2hksX+Ay5PL 7vGiWzi+Av2p7cgm9qhrIEoI4xSQ5HcodoN34Ue/UAyk6K5o/8/6JfSkD4wGmwln9D+h 83e2g6w2w43CBiNzxoVogpJRlAOp8lTWzRnf088kV5z7NoN48kvO/Kqh/4wYF+sPFVqn j6d55Uea7jAQxC95bSwWI+1wPMOS63kP77nEcVGMY0LvIPT/OzKX/c7vhdQbL+rWXZTj LaZw== X-Forwarded-Encrypted: i=1; AKwUvByHhvtQO+CvhPyIKXJQaU2rl2ZdjETzQZh1aRv2tgPdU4qo7AcnixZ6SLpKODyU4/HyFkXgbHyak3M=@lists.infradead.org X-Gm-Message-State: AFq9FYLlVo/a3YGJyBzA+17TVNe6TMk3TgfkT90SCu5J+UMQjJ5SOzCT ff9wJrR55I8WF6H2HcuUr6ub9BuDYu0+rd78hdCHWZe9y0XklUF20OCK X-Gm-Gg: AYBFou2VobgVGyq2JjHYqStTX4Z9o7cd34BdJm8Z4fZ8zNdj7IOUB2FDuDQVSTzWR9g 0Wuxe0UnO255dITcFvYQkRT6UUrN3rmC+KqHFG4XuWJkwbWnH+o/MCDTHBANEz3uPPPPt4QaBAb B79AEDF5GPS5SuCBIkZNj1fRrzPPjzTvlQ77+S8DKqb7LKOqPr2rbCFWaIQXKAgRg+WS7mZRXIB ZzE/L39TPLWRVoubFjP5/YUiX/T59MtGKRUNzoR/xl4oaFazTSzS9FYRlgbBPBwaYWWUsGMPYO6 QTbWUeWW4WeHFQCuNWvjQKF34t79uXFYR3e5WKI1N7tJu8y1OMeBOOYVNzWRVC/Dn2q5IT4wNZZ ScZb9R6GIL0pfNMcVFbGv7HCiv6hmaByKXB/ouFUEFDZgJmYohYaQrfZba0OFQYQ7WJIb3bVEG5 XfbfJ1hvEPaKF11DUcc2xUamAvuxc6lFitf+MDtqBP/YAE2ouP4MeG7orOVonW3m29CGwYyuyF4 tjHLLonScUzdt+/cGOcgVInb3QdnWGOA1NhWFGTRWPHIRS37SJbsYSUBOmrG4e+gA7U+oVuZ3Ta BAMqKtxncgozUZ19d0h5B9NRo/NFnsxJ4x3LjfEs7BiH/xF1+KngWY6qTr0kSkgq6XVfj2d+OUP Ih3/2Vl+xqBP3RHcHI7sDXSJp2W/ISGCK5FVx7VfZWoMvHdOVAtY= X-Received: by 2002:a05:620a:26a1:b0:93e:c12c:fbc8 with SMTP id af79cd13be357-94408d361damr565214385a.68.1793227404758; Wed, 28 Oct 2026 15:43:24 -0700 (PDT) Received: from paul-white-HP-Pavilion-Laptop-15-cs1xxx.mynetworksettings.com ([2600:4040:ad65:1c00:b8:5aeb:4bda:886]) by smtp.gmail.com with ESMTPSA id af79cd13be357-940f0787d96sm1370085685a.28.2026.10.28.15.43.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 15:43:24 -0700 (PDT) From: Paul White To: anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr Cc: kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Paul White Subject: [PATCH v2 0/2] KVM: riscv: Unify and optimize FP register loops Date: Wed, 28 Oct 2026 18:43:07 -0400 Message-ID: X-Mailer: git-send-email 2.53.0 X-Archived-By: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261028_154327_098113_AD0443E1 X-CRM114-Status: GOOD ( 16.95 ) X-Spam-Score: -2.1 (--) X-BeenThere: kvm-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kvm-riscv" X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 The change to both patches in this series is a structural/architectural one. Both functions set_reg and get_reg use identical code to locate the register the application specified in the token even though they do different things with that location information: the set_reg function adds data the application requested to send to that identified location (in the copy_from_user function) while the get_reg function retrieves what data is at that identified location and sends it to the application (using the copy_to_user function). Everything else is the same. That is the only difference between the code. Therefore I was able to apply the same solution to both of the function's finding-the-requested-register parts (which is everything up until the final if statement) which were filled with redundancy. The solution I came up with is to create local variables for the entire function for all the variables of the original code that would be different, depending on the floating point type. Then once I ask whether it is a double floating point or single floating point mode, I assign the aforementioned variables to the values they should have for that mode so that when I go through the if statements that ask whether the requested register number is a status control register or data register, I only have to go through it once because the respective floating point values/addresses would have been assigned to the aforementioned local variables, so the whole code kind of changes or is tailored to the floating point type. This architectural change/solution will make the cpu execute the code faster (as the cpu will have less decisions to make and the bare-metal math used to figure out the address of the register is executed faster by the cpu than looking up object properties and array indexes), is more maintainable, and is more readable. --- v2: - Both patches had the same flawed line of code. The checking if the token's size was 32 or 64 bits line allowed token's with mismatched sizes & types to pass. I fixed this by checking it had the right size for its type by replacing the u32/u64 parts with a mode-dependent local variable, byte_offset. Paul White (2): KVM: riscv: Eliminate redundancy in get_reg function via pointers KVM: riscv: Eliminate redundancy in set_reg function via pointers arch/riscv/kvm/vcpu_fp.c | 124 +++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 52 deletions(-) -- 2.53.0 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E84D5606A32C for ; Wed, 28 Oct 2026 22:43:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=PdOVfxB+; dkim=fail reason="signature verification failed" (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=kDiUv/LP 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:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Unsubscribe-Post:List-Owner; bh=Ger42z63CA2YjuhnELteTgbOqqY7efgFKHyk5vcGujc=; b=PdOVfxB+ZDa2f3SEWKQliygTWZ dQkBJoH7QR8mFQtkpX3ArNVaUv3BG6dIzPYFsTzuHVzehKZLtQUesLg9i2g/r93UJTz975WVePJ97 9KLNTUghLlp7werfQKKZSI0AQwgABAQOG40HvD1hbNrG8ujvs7yKdOay4e34HoxCL1COLhOEd5sfA WNuhmmXyIcdBMZvi9kRaqTHbLbCoC5IgllfXUVb0LGtys9rjb1Ooa3JxPEOcI8sR04/XWOHVP0F65 gyKFFRKW51hszKAPVHkZvDhB3mMEooe0GlFqyE87v1YxjJ9/S8BLKmHZ170wgoqp/B0d/rEUvCPDG ad0zvD7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xMCMk-000000081wO-2iK7; Wed, 28 Oct 2026 22:43:30 +0000 Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xMCMh-000000081tv-0Cb0 for linux-riscv@lists.infradead.org; Wed, 28 Oct 2026 22:43:28 +0000 Received: by mail-qk1-x72b.google.com with SMTP id af79cd13be357-93cb9e9405fso78315085a.2 for ; Wed, 28 Oct 2026 15:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793227405; x=1793832205; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=kDiUv/LP4cjPX6FihPNtG7yUBj6MQ25DoW9cQnbObOcdLUsgh12kIp8IZv4JfWn+4z I9zGYEsRqyH8+1vUPQNSZ5Sc5bOVci6nyKUW2729O8cZU6Uv8LJkONU8ENQCrZwY81xy oPAuaN56wT22SGgN3oRpO+iJoAwxioC2fDndlbjHb5f7q37SfpBtrqG44Y9Xisr2BMge d1TEkLGphwuPbwPaEQcrCtlhrLFbAPO/RUNJX61QYxfD/sGnxx33ni1TprkQnODBnNn+ 9PF5leruduuizlU1pkdK+9DwTrXb34LFn299pbTL3EURQYOZQvp3WfaCPv6ndRBZcTnE ziIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793227405; x=1793832205; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yECpefA28/MXqj384Qufm+rtjJRCtVDFYCVrS7mE970=; b=MgEY4t/1StDg25Wv6FohpqH+cruIhdD3e/DGRGd2JJ4gC4+qbflxDN5vgI0yuG2icV UCStsYao6Wg89pY+n0JzYLH7TzvIsIpne1ghGZ5+MUbbb3QR7wM5E64H7l9BE6fI/Fzm Co2Ig8nFe/IMmEsgPxihN+NbWB/jAW2l9Ivcy82jtayG2vw4QFtibd6gQdFes5KMKgya 2srzwSEL1EBfPW2FMVVsDHE8o9GH8UUgbwlrXvwxiGqg3mCxdMlg4vqmsNbw75s/RALw nq7P+by/w/Rwa7Yqdu9yWEy5SZMHY13vDz/KvLyZZD8iWQ662kL/qDSMchpOfkHfNuTz vJDQ== X-Forwarded-Encrypted: i=1; AKwUvBzXOyNa1E76pcm94HN9h3ypB+8+96NHiiDtiS1P/02gyqJky2IzRRikcJy3CnHJ7M5pR34XHIHvQ4noaQ==@lists.infradead.org X-Gm-Message-State: AFq9FYLMoUfwPSOveYxzhpQtxRYSn/FCK1WV8W0czMYpEcEDtRXwfMly dGBRnF1W/BTQap8xSxt8bvmQTC2y6Mjl+Ub3gnhyeyGtSXDe+TtlKyTK X-Gm-Gg: AYBFou07WOoO0ZsT8lyrH1Q4Ag9TxzxlTUTA1VpnPKUcrrHNVCyqP+KAxRzL4k90krN 5QWWvCRBksVm4rdtshFV3cTHfCeApUTjtsUAgl4zYCx4D8kRW1ZEAFA+njUODyiKq6KADxRyf94 xCMof9DnaeSwqN50YZPfw36v8zEVTNbRncKwKiOBhIKpmL36xfXdAQIHq693cWQo9WyXy/jbcbX wsyT2BJB+f5iuLfUSXee2Pz5ZnOri3s5tYYpOtVxOT555TGBFu2jjxmGlSNlI7bBJ127/MKpQ7c zaeE26vHdfx9CWWw0ZCNdsvMXORrUoD9819uuK4+Djq3Wyxi2+3HWCT7C+5N8rgcNh/wwKeX1eJ imjpKscHnPlPH04T/sR2QAnlbnel03eESblIKBHnxVoim7GIraVDqJP3tIeLb/Pc89w2wehM4xC TVk7Zl0mE9ExYpKcL2YlhlRjVpVR5L4X8LlHJEuvkd7uF75iST91nG+u9+mi3AhWpjdbnQzQ2Yt vHD6fDGsuFOYaqOI5qas9X5b32B2Mlze4dfwttCRnyQxqTl+tvYGbh0DZWCKRosDW2Bjq6a6MBW au/iRsxHCG8ffEQF5eDrFsiXeh0S9xKzJiERmJG4DHFRMZVWW5onacGRrttzni6FMuoRpNniS0X 7X3mbrPwlb9I7EZi7OD82nCZpmoKtSzuCxl4P1jPi1njBQcJ9kxA= X-Received: by 2002:a05:620a:26a1:b0:93e:c12c:fbc8 with SMTP id af79cd13be357-94408d361damr565214385a.68.1793227404758; Wed, 28 Oct 2026 15:43:24 -0700 (PDT) Received: from paul-white-HP-Pavilion-Laptop-15-cs1xxx.mynetworksettings.com ([2600:4040:ad65:1c00:b8:5aeb:4bda:886]) by smtp.gmail.com with ESMTPSA id af79cd13be357-940f0787d96sm1370085685a.28.2026.10.28.15.43.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 15:43:24 -0700 (PDT) From: Paul White To: anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr Cc: kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Paul White Subject: [PATCH v2 0/2] KVM: riscv: Unify and optimize FP register loops Date: Wed, 28 Oct 2026 18:43:07 -0400 Message-ID: X-Mailer: git-send-email 2.53.0 X-Archived-By: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261028_154327_102122_A2BE3439 X-CRM114-Status: GOOD ( 16.91 ) X-Spam-Score: -2.1 (--) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 The change to both patches in this series is a structural/architectural one. Both functions set_reg and get_reg use identical code to locate the register the application specified in the token even though they do different things with that location information: the set_reg function adds data the application requested to send to that identified location (in the copy_from_user function) while the get_reg function retrieves what data is at that identified location and sends it to the application (using the copy_to_user function). Everything else is the same. That is the only difference between the code. Therefore I was able to apply the same solution to both of the function's finding-the-requested-register parts (which is everything up until the final if statement) which were filled with redundancy. The solution I came up with is to create local variables for the entire function for all the variables of the original code that would be different, depending on the floating point type. Then once I ask whether it is a double floating point or single floating point mode, I assign the aforementioned variables to the values they should have for that mode so that when I go through the if statements that ask whether the requested register number is a status control register or data register, I only have to go through it once because the respective floating point values/addresses would have been assigned to the aforementioned local variables, so the whole code kind of changes or is tailored to the floating point type. This architectural change/solution will make the cpu execute the code faster (as the cpu will have less decisions to make and the bare-metal math used to figure out the address of the register is executed faster by the cpu than looking up object properties and array indexes), is more maintainable, and is more readable. --- v2: - Both patches had the same flawed line of code. The checking if the token's size was 32 or 64 bits line allowed token's with mismatched sizes & types to pass. I fixed this by checking it had the right size for its type by replacing the u32/u64 parts with a mode-dependent local variable, byte_offset. Paul White (2): KVM: riscv: Eliminate redundancy in get_reg function via pointers KVM: riscv: Eliminate redundancy in set_reg function via pointers arch/riscv/kvm/vcpu_fp.c | 124 +++++++++++++++++++++++---------------- 1 file changed, 72 insertions(+), 52 deletions(-) -- 2.53.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv