From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 78BDF21D3E9 for ; Wed, 30 Apr 2025 11:45:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746013534; cv=none; b=COHHHlCBeyG+eYmAJXKZrLtxnGovQ5qsq63Qv16kusxqfVKOAnvKJtohc8nkmBugfl4bxjAXa2/AFvwb6JTBqZugr+Nugf63dlHiZG71AQVxTYSWSVZUf38uJWiAOuYDmIl5qplOFiZP9d9xtL9xcCZrYEuA8BgfvXBR1WuQHTU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746013534; c=relaxed/simple; bh=CJJauCshp21Gt8IYh7pezCpA++nAGgiCyqfq7wFZA1I=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=XLaf3kus53aFKtQP0qhaG+uKDfhb/v7vSpIUrfJb3UvMMyPulw+ZuF5E2ffBZAkKZbQg5ViqyxzQQCU7VO3W82Dbdx0t+RqnjU3ixzzqt9HkW/wg1PzUKaWW2+XyY6nJjvUIsGuVYXZucDWVCgCs7/RlzpNhR3UovmzovxqrnTY= 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=LctQzrmY; arc=none smtp.client-ip=209.85.221.44 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="LctQzrmY" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-391324ef4a0so395314f8f.2 for ; Wed, 30 Apr 2025 04:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1746013531; x=1746618331; darn=vger.kernel.org; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MwfMy0+KN//YvkfkLkShPPR01KHLLVwze7q8vnuMUqk=; b=LctQzrmYVxuoiKEcNFGPoiJMVuDod7iHS+hyKPuTm1tvzI5wa7YDEVAsIATZ5Z5S5/ AtiXmR91rOSOIHeorlEwEtQrYvSAYlbDuElhGo5+hOEx/en1LwEi4fvftqUdp6GNhm27 F6tYrV+dLFVFn6j36bEYPMp0iXshfWGlZqrc7uv4iSiIwxpOVMKjCB45+C1f/qwNfxvM l8VTgDD8c3rOp7CVwfP/B0sLHzhuFNrw5tD33BY27ks8jh5TOZaJy59VPTA6bOnXsPiA W8GfM5/cquuaPX9ewqoizSJhRcdRvOsnmNtK3qcZV8Vr2M3InW8CzYKggGJJ7URZ29X1 sTtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746013531; x=1746618331; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=MwfMy0+KN//YvkfkLkShPPR01KHLLVwze7q8vnuMUqk=; b=fn5S+94VAW3aw7hAKajGruOCP7h8hchC0yFNQ2D67cW/QGWrBhQ+LzHBOuREqZ0kDg FiGUuGTr36tdsUdZf4n0Ym5k1+bh9CunxLEf5e6ieksmwYqSHh58FI8KNIEPkukObNaK hvpVukfjdNAienup8kW0ocFUB617GKiW6pzvvY6ZTXoH3SGYP4oqhTJb6ajVx9k0MsKW U6n4OvoJ1R6t/gql0OTLIcIuojCJAV8m+PdpxeTUTRy4oopSxG9czwE5ZLEK4fwpwP0C HBFt0ncu60YfEmmYfmaMy95f52eXBOqMXasTFTynoRkcv54R5cmMbbJu+nUVsqIskAiR MC1g== X-Forwarded-Encrypted: i=1; AJvYcCV4W/DhPcwk2VzFlS6Dc6qckpGyOT0w9QiTesFoGth7zSx9o0O7T9tcgVehWqdJWhTY6NNCtsU/2B4r4fA=@vger.kernel.org X-Gm-Message-State: AOJu0YxLp+DYDdAAq+mUHZzvrYyCH0vUYeOUCtdS+40dEL/weRWB9bQP 6EjyDt2ZuPJCW8dXQAmO1eiRWGkN/EZC3jedtEw4lU80TglUwvuILFu1SdNFFsM= X-Gm-Gg: ASbGncs4b3IN03sFp846LNZahSDPLwcDKRCO3dSareG0unpGXWQ3p77EniEtkqklCSG 4bVG50Zpfnnznbk6Z91Y4phy3/FXBZGzyM6WfaVi7H3Zi/Tyc0c6rpDDogkujl5gSlpUVcyhnQZ WYsWz+ChAZ/vp25u6AVdyS+o5hEU3D7EjYdi0VoHrShHgdDvv5JmbeWGNq0Ip9468rYeZznj6j9 YZoJ57FhIVYN37ujGmfMj5Meh6QiEYUDA7s3gKQQL8W0GR2UAX2O/X7KVKnq0vuVlrjYmYSWLAT WTBJWrH2rvmXbZh0RG8zMwsi6Gd5KBPd8cZWnttiT2uvic2vAMwQGfRIjCpuQKUi/LjBUSZbss/ 3OQMxpHC964A= X-Google-Smtp-Source: AGHT+IGPsHFo0i2I8e2STgcf8/9L1wSmTK1gIO5CuUV/Z9SjXZXm3h77FFhC8bIycStr7wFr3jgBMA== X-Received: by 2002:a05:6000:22c3:b0:3a0:678f:8023 with SMTP id ffacd0b85a97d-3a091a624b4mr22754f8f.4.1746013530645; Wed, 30 Apr 2025 04:45:30 -0700 (PDT) Received: from localhost (ip-89-103-73-235.bb.vodafone.cz. [89.103.73.235]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a073e460b2sm17013970f8f.70.2025.04.30.04.45.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Apr 2025 04:45:30 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 30 Apr 2025 13:45:29 +0200 Message-Id: Subject: Re: [PATCH 4/5] KVM: RISC-V: reset VCPU state when becoming runnable Cc: "Anup Patel" , , , , , "Atish Patra" , "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Alexandre Ghiti" , "Andrew Jones" , "Mayuresh Chitale" To: "Anup Patel" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= References: <20250403112522.1566629-3-rkrcmar@ventanamicro.com> <20250403112522.1566629-7-rkrcmar@ventanamicro.com> In-Reply-To: 2025-04-30T15:47:13+05:30, Anup Patel : > On Wed, Apr 30, 2025 at 1:59=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> 2025-04-30T10:56:35+05:30, Anup Patel : >> > On Wed, Apr 30, 2025 at 9:52=E2=80=AFAM Anup Patel wrote: >> >> On Tue, Apr 29, 2025 at 9:51=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 <= rkrcmar@ventanamicro.com> wrote: >> >> > The point of this patch is to reset the boot VCPU, so we reset the = VCPU >> >> > that is made runnable by the KVM_SET_MP_STATE IOCTL. >> >> >> >> Like I said before, we don't need to do this. The initiating VCPU >> >> can be resetted just before exiting to user space for system reset >> >> event exit. >> >> You assume initiating VCPU =3D=3D boot VCPU. >> >> We should prevent KVM_SET_MP_STATE IOCTL for all non-initiating VCPUs if >> we decide to accept the assumption. > > There is no such assumption. You probably haven't intended it: 1) VCPU 0 is "chilling" in userspace. 2) VCPU 1 initiates SBI reset. 3) VCPU 1 makes a reset request to VCPU 0. 4) VCPU 1 returns to userspace. 5) Userspace knows it should reset the VM. 6) VCPU 0 still hasn't entered KVM. 7) Userspace sets the initial state of VCPU 0 and enters KVM. 8) VCPU 0 is reset in KVM, because of the pending request. 9) The initial boot state from userspace is lost. >> I'd rather choose a different design, though. >> >> How about a new userspace interface for IOCTL reset? >> (Can be capability toggle for KVM_SET_MP_STATE or a straight new IOCTL.) >> >> That wouldn't "fix" current userspaces, but would significantly improve >> the sanity of the KVM interface. > > I believe the current implementation needs a few improvements > that's all. We certainly don't need to introduce any new IOCTL. I do too. The whole patch could have been a single line: diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c index d3d957a9e5c4..b3e6ad87e1cd 100644 --- a/arch/riscv/kvm/vcpu.c +++ b/arch/riscv/kvm/vcpu.c @@ -511,6 +511,7 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vc= pu, =20 switch (mp_state->mp_state) { case KVM_MP_STATE_RUNNABLE: + kvm_riscv_reset_vcpu(vcpu); WRITE_ONCE(vcpu->arch.mp_state, *mp_state); break; case KVM_MP_STATE_STOPPED: It is the backward compatibility and trying to fix current userspaces that's making it ugly. I already gave up on the latter, so we can have a decently clean solution with the former. > Also, keep in mind that so far we have avoided any RISC-V > specific KVM IOCTLs and we should try to keep it that way > as long as we can. We can re-use KVM_SET_MP_STATE and add a KVM capability. Userspace will opt-in to reset the VCPU through the existing IOCTL. This design will also allow userspace to trigger a VCPU reset without tearing down the whole VM.