From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EE75239E62 for ; Tue, 19 Aug 2025 16:03:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755619438; cv=none; b=WvK5jAnIKMqWV071B8N/ZZTE1JSEvHMPNurvABi+d3cojb1BYtkfF9/Fa9KuekBeXYGIUOQme7vY77Uho8UwUiRE9CTcdVDJhdsmhdcrIevP4USIHMs8UwpmbdqlFwmMZ8HYp2SirlS/5KPpKD1YihStO7OfdQfUig6+qs93D6I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755619438; c=relaxed/simple; bh=ElsK78evf/jSWVT/An81m0pfn9gX4XVTLMYXztIt85c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eWsb9r5RkzUKRf0WBteQo+L6rIupiK6VtvKWhVLqyRUc2J7Y3OXQxkd0fAfT9ZI3eQtHx4kBGtN2qWYxrS42ZFzdKLDJ08O50SW5H+Xrh0jntcnrxLgAtA3UH1wvi71mjm0PJQXvGo0eqS9BR+tOCO4Oz6YeQWgl/AIEvhrw348= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=ByKqp2Fi; arc=none smtp.client-ip=209.85.167.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="ByKqp2Fi" Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-435de5ccff6so2708888b6e.0 for ; Tue, 19 Aug 2025 09:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1755619434; x=1756224234; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yC88mGoSbqZk1f9KFdafn4QiNyHx2q3f5J/pFIXzL8g=; b=ByKqp2Fi4w4PPaHkLxoaPjtNm3qQV2I1jvR9DsgVqEZoI+hZJx4uCvmh7HVTq4bm+O dgnku9e/iLylYxHg4m4M3GtlbuUpZ4c6jbLkBYuNmaJ9Dskqe7EMEFs1XcPace7jaOkT MY4X7Dn1vcirCgaQk4JFcE28d9yTwaPfxXja9sx/6Wz7CED40zYZzihKEtkWvqj7JkE1 Lznb0++JfOJcasQUkUQN/Lm+N9WWo8kKydHPItDh8s1qDC0RrIy6fNV5Fixd7D6zVd9M NWIycDmA6asXjvw1/XVsM6qa4PN8DoB/RdrE1csoDMMdQ6l0ww/fiR9J+83gXmJNvCGf ybqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755619434; x=1756224234; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yC88mGoSbqZk1f9KFdafn4QiNyHx2q3f5J/pFIXzL8g=; b=DhHXjxwE3DvRB/rSVL2eggC7utA4krMjH8qw+UfiB+zMnkhlusxKQ+hkrQ7vcWkhYu 66DzTGPdmUpsAihV9crh8xKXbfscdOq2DcXKPPYNWk0sRULvUD1W1U9bgEbCqdAFM1Ax b96BjKpzWkhu+YWfOQiYlO6we1Rl0VoacJAZpO22+3t3fPbPbv0qO6hm9hQ16ZRB8fz/ mUhHPkkon84gyyqo5jSIesBDG1XLeHBPr5+XcAHwUx+NS+FQHGktvA5AZZtgzt4m9bvz eDTcjswmthMpzR75tKF7hbaU6tg7L7Q6tO1Z1LTgMJuA8+oLZHBrO42vxoBclK8DmKSH S2EA== X-Forwarded-Encrypted: i=1; AJvYcCUVmc90nUNvmZPMzAKsrOQpE9qybUdTuvy8q4xHx0Et07x9szz7x0z6yidTWuFyJclOPhhQRHeBBBMsgW8=@vger.kernel.org X-Gm-Message-State: AOJu0Yzi32XlM9mhnIYU7xtyYEgnVmpvdHlW0yuR0+JnPfuvv5x4ptO+ 8DD4XgkxhYWvidRqGIyhDBHL/qOz99pc4etZZ8pWB7uExZrO53mteD3jVCZIBGyPvOA= X-Gm-Gg: ASbGnctfo2ymeKJDlkfO4u7ixJEJBiSRfOJhdel+TMSyhoxUDRkDr+gjCbZ8RneEIMa KsiAG1b52BW6RoiXSTFBiXneqNga+1l8HVjwdZIpxeT6sc85Sf3r/0gLbNYJ0R7OUUv9EOV3wwG zj0ucvbCLaE6LgI+FDvlofgKxo2ggtDzTilmuNkOCuC5/GIYLGGEl1HSCklNOP3hSsJmwltaACI 2TQCEMkSjx79Nh+q8IeuyZ340US0rdNrvuiqGMBkVBKufbkWQL+l6S1nz4E0M5d0wgCraxK6m7n RmPsjXKXNgE6FZI0tPTgkCxHXG9zp+l3wpRnB6JoQL8JPGWdsx7OIdKrIO2FdAWowjZ4eZn/qCZ Y67ShfqRiZKEr8ypyiXkNHt8ZWJpfTGMOulU= X-Google-Smtp-Source: AGHT+IG/y8PrsSJqgoq3CvRF+MG0X5iWsQigK66jrK0xGiIjJMRnFVwGXiYkN7AL+ccvUXU/i/hDzw== X-Received: by 2002:a05:6808:1b0e:b0:435:744c:9297 with SMTP id 5614622812f47-436cdca93famr1950579b6e.16.1755619434540; Tue, 19 Aug 2025 09:03:54 -0700 (PDT) Received: from localhost ([140.82.166.162]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-50c949f75d1sm3510509173.79.2025.08.19.09.03.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Aug 2025 09:03:54 -0700 (PDT) Date: Tue, 19 Aug 2025 11:03:53 -0500 From: Andrew Jones To: Jinyu Tang Cc: Anup Patel , Atish Patra , Conor Dooley , Yong-Xuan Wang , Paul Walmsley , kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] riscv: skip csr restore if vcpu preempted reload Message-ID: <20250819-62ec62e0ef8ed3d928f56ddc@orel> References: <20250807114220.559098-1-tjytimi@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250807114220.559098-1-tjytimi@163.com> On Thu, Aug 07, 2025 at 07:42:20PM +0800, Jinyu Tang wrote: > The kvm_arch_vcpu_load() function is called in two cases for riscv: > 1. When entering KVM_RUN from userspace ioctl. > 2. When a preempted VCPU is scheduled back. > > In the second case, if no other KVM VCPU has run on this CPU since the > current VCPU was preempted, the guest CSR values are still valid in > the hardware and do not need to be restored. > > This patch is to skip the CSR write path when: > 1. The VCPU was previously preempted > (vcpu->scheduled_out == 1). > 2. It is being reloaded on the same physical CPU > (vcpu->arch.last_exit_cpu == cpu). > 3. No other KVM VCPU has used this CPU in the meantime > (vcpu == __this_cpu_read(kvm_former_vcpu)). > > This reduces many CSR writes with frequent preemption on the same CPU. > > Signed-off-by: Jinyu Tang > --- > arch/riscv/kvm/vcpu.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c > index f001e5640..1c6c55ee1 100644 > --- a/arch/riscv/kvm/vcpu.c > +++ b/arch/riscv/kvm/vcpu.c > @@ -25,6 +25,8 @@ > #define CREATE_TRACE_POINTS > #include "trace.h" > > +static DEFINE_PER_CPU(struct kvm_vcpu *, kvm_former_vcpu); > + > const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = { > KVM_GENERIC_VCPU_STATS(), > STATS_DESC_COUNTER(VCPU, ecall_exit_stat), > @@ -581,6 +583,10 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu) > struct kvm_vcpu_csr *csr = &vcpu->arch.guest_csr; > struct kvm_vcpu_config *cfg = &vcpu->arch.cfg; > > + if (vcpu->scheduled_out && vcpu == __this_cpu_read(kvm_former_vcpu) && > + vcpu->arch.last_exit_cpu == cpu) > + goto csr_restore_done; > + > if (kvm_riscv_nacl_sync_csr_available()) { > nsh = nacl_shmem(); > nacl_csr_write(nsh, CSR_VSSTATUS, csr->vsstatus); > @@ -624,6 +630,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu) > > kvm_riscv_mmu_update_hgatp(vcpu); > > +csr_restore_done: > kvm_riscv_vcpu_timer_restore(vcpu); > > kvm_riscv_vcpu_host_fp_save(&vcpu->arch.host_context); > @@ -645,6 +652,8 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu) > void *nsh; > struct kvm_vcpu_csr *csr = &vcpu->arch.guest_csr; > > + __this_cpu_write(kvm_former_vcpu, vcpu); > + > vcpu->cpu = -1; > > kvm_riscv_vcpu_aia_put(vcpu); > -- > 2.43.0 > This looks like a good idea, but can't we also apply it to kvm_riscv_vcpu_aia_load()? And, if we could track whether or not the kernel uses FP and/or vector then we could also avoid restoring those registers when they haven't been used. Thanks, drew