From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 8748230BF4B for ; Tue, 19 Aug 2025 17:35:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755624949; cv=none; b=X5s1JBB5tN8awjm0x953IylyPSpGG6MfwURm/A1sKtT4veWIIOZLQtY8vUkgsgSXdcdsA+ux3qbAqXJt4rvhpsdvx8/gJD8uiMBlsVr8JQH1c7eiLltpEabFKhA59sosB+wnoLR9cVATOIJVjRDrttx+o/cj2nJfPFbx8nk9aWY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755624949; c=relaxed/simple; bh=3lx/6/xRZF2aURKCYXk81xVXA9kIZnoFiaggniSCdKM=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=i+1IaAgQwO+SfX00as4S5SXMyRqCCYie/He+iMJ2aaYfJps3fLzhn+WhjvG6UHDorJGgDakFZG9tObq9JteislblWlKRnproafjP1Us8hMUO12zT8AHS2AsBjeenXAhKLpzBf3+Q7ZTiEQSRlqFgTfG9bgHR4MI87t6AWjQCxnc= 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=fdN5z0p7; arc=none smtp.client-ip=209.85.128.50 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="fdN5z0p7" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-45a1b0049a9so2052115e9.0 for ; Tue, 19 Aug 2025 10:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1755624946; x=1756229746; darn=vger.kernel.org; h=in-reply-to:references:subject:from:to:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HriY9Mwm+2fMM0vnEvPFFz/UXLfXmL7avJoov+0cHIs=; b=fdN5z0p7Ve1LwKx8C8KdIcc6Hk+jxajMirUok34CF8jIAKlY4X/pulTnLgksyDj38R ySeTUzGp0hQH6w12RzNAYI5ffKWUJizaWd0DQKgAu4FJLs2haKDPAwOq+kcmUKuO3iuf n7h/dxhIQ9A61QQRKfdx2iRQgdao5WQn2kMahwsxxjWD120n/iq9aqPcPF8o0vmV6gKj KIX8lZUKgd5K+HRB5fzhmrb0NcqaYkSoRCJlrG7WvtbMrBnXOVlxVrQEMJojkxc10tvS aGIHp7NJnd5pzvccaXx4AQ4N9k4wQ0TMDpjQgCW2gGT7CeLYFM67mxU7wXz0irENZec6 am6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755624946; x=1756229746; h=in-reply-to:references:subject:from:to:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=HriY9Mwm+2fMM0vnEvPFFz/UXLfXmL7avJoov+0cHIs=; b=O/B7MThidQiEndstGPiBeE+WgzuwXGUegidGUjwLxNjqEoyZjlIpBtBnwZPLU3y8vA 1uW9tgmoy/xQcVpbw/zEvHtdEPZArDAsos9bEM6JPb89p/80DK/k25SBnLZAhgLthrBv d+w2pw2VMmsysoKoyYgrl3pjGZi18poRbRICEwp6QODXhBTF3rJjyCI/JfRNUpEGD9ob xUGM8dLphNUAQ8i3uD4wS47SADaySZdg34qcVvKdy0opkWJCIO5JL+Qd8NpkWXWit5cT imjIfw2iom/E7DBVmvuGKHT60b776rh5l0Zfbkd2kanzze8pBFTKzyVc4zCdBVyiaNaF DUVw== X-Forwarded-Encrypted: i=1; AJvYcCV6EDa1qFl8cnwXD2wR1GlZpOJq9dcxBILs7hmyZNaCdDtIN9GiMoOeq+5zDdGrF9GsRxMh0ql2heztFPw=@vger.kernel.org X-Gm-Message-State: AOJu0YxK+DOcDcRFxvXHAjJhwa0x1Jm8N0bF836zYfllwTLY7t0EgM8H iz0cQiI+KD98j2gta3zcuNN3HpQBodQjRENPEI93nu/N1Y4q3K4u68vciOT9apb4HGI= X-Gm-Gg: ASbGncvtenabuKG5LZ1YJChCQNtshxagNFhLdcP4u1ZqfWJPLGeYfI+U1RXmwiuaRMd rmRpA7MxVoA9BXI6D9LlWB7u714ZSIQvAId445MsMRh+RyqZufBUtY/CoBDMJhFB99WeOCAk3gh XEilmSg5jChQBSgd6zlCUJVPX4luiHNk6ejHiTw0yeeniJdHUL2mI3CM/kjPwlYfYkdslakz5S3 7RGXsKVI271HYUKzU93EVOef/hkSvmcXRW00ZU7KZ28AGvOPdhdaFfM8p7jAAxPqjAppaukM0w2 koKmtgw/jReyR7m69Vypi2wQBvYr5p32BxsZn+/VaM220MEOEG++HYAffmUzHMqeFJBWKvkY+CQ JGgebedJKUNgpuf9Mpi8xV8qCpF8IVg== X-Google-Smtp-Source: AGHT+IHdHc43/qbPeSuFvpTUjrq1NXmEH79kFa8+PuZKM64k2/KwBznp+KjWl/svIF/2Oq3kUoCIug== X-Received: by 2002:a05:600c:468f:b0:453:7011:fcdb with SMTP id 5b1f17b1804b1-45b46b7681bmr4785225e9.1.1755624945689; Tue, 19 Aug 2025 10:35:45 -0700 (PDT) Received: from localhost ([2a02:8308:a00c:e200:e7d6:daad:8c97:a08e]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-45a1c6bc85csm221551445e9.5.2025.08.19.10.35.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Aug 2025 10:35:45 -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: Tue, 19 Aug 2025 19:35:44 +0200 Message-Id: Cc: "Atish Patra" , "Palmer Dabbelt" , "Paul Walmsley" , "Alexandre Ghiti" , "Andrew Jones" , "Anup Patel" , "Paolo Bonzini" , "Shuah Khan" , , , , , , "linux-riscv" To: "Anup Patel" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= Subject: Re: [PATCH 0/6] ONE_REG interface for SBI FWFT extension References: <20250814155548.457172-1-apatel@ventanamicro.com> In-Reply-To: 2025-08-19T21:22:27+05:30, Anup Patel : > On Tue, Aug 19, 2025 at 5:13=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> >> 2025-08-19T12:00:43+05:30, Anup Patel : >> > On Mon, Aug 18, 2025 at 3:59=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> >> >> >> 2025-08-14T21:25:42+05:30, Anup Patel : >> >> > This series adds ONE_REG interface for SBI FWFT extension implement= ed >> >> > by KVM RISC-V. >> >> >> >> I think it would be better to ONE_REG the CSRs (medeleg/menvcfg), or = at >> >> least expose their CSR fields (each sensible medeleg bit, PMM, ...) >> >> through kvm_riscv_config, than to couple this with SBI/FWFT. >> >> >> >> The controlled behavior is defined by the ISA, and userspace might wa= nt >> >> to configure the S-mode execution environment even when SBI/FWFT is n= ot >> >> present, which is not possible with the current design. >> >> >> >> Is there a benefit in expressing the ISA model through SBI/FWFT? >> >> >> > >> > Exposing medeleg/menvcfg is not the right approach because a >> > Guest/VM does not have M-mode hence it is not appropriate to >> > expose m CSRs via ONE_REG interface. This also aligns >> > with H-extension architecture which does not virtualize M-mode. >> >> We already have mvendorid, marchid, and mipid in kvm_riscv_config. > > The mvendorid, marchid, and mipid are accessible via SBI BASE > extension but not any other M-mode CSRs hence these are special. > >> >> The virtualized M-mode is userspace+KVM. (KVM doesn't allow userspace >> to configure most things now, but I think we'll have to change that when >> getting ready for production.) > > The RISC-V architecture is not designed to virtualize M-mode > and there is no practical use-case for virtualized M-mode hence > WE WON'T BE SUPPORTING IT IN KVM RISC-V. Oh, sorry for the misunderstanding, I'll be clearer next time and talk about implementation of the supervisor execution environment. KVM+userspace provides SEE to the VS-mode, which is to VS-mode as what M-mode is to S-mode, hence I called KVM+userspace a virtualized M-mode. > FYI, the KVM ARM64 does not virtualize EL3 either and it is > already in production so please stop making random arguments > for requiring virtualized M-mode for production. Yeah, I agree that we don't need it, I just had to provide so many examples in the previous discussion that I went into quite niche cases. The increased flexibility is similarly useful for more important cases: we can't avoid "virtualized M-mode"/SEE, but we don't have to completely implement it in HS-mode. >> For general virtualization, we want to be able to configure the >> following behavior for each exception that would go to the virtualized >> M-mode: >> 0) delegated to the guest >> 1) implemented by userspace >> 2-N) implementations by KVM (ideally zero or one) >> >> We can have medeleg, and another method to decide how to handle trapped >> exceptions, but it probably makes more sense to have a per-exception >> ONE_REG that sets how each exception behaves. >> > > No pointing in discussing this further since we won't be supporting > virtualized M-mode. I understand, back to the current series: I think we need to provide means with which userspace can control which FWFT features are enabled, because KVM just exposes everything it know and hardware supports right now: 1) Migration between different systems would be hindered 2) We couldn't add more FWFT features without breaking the SEE The (2) is similar to how we must set ".default_disabled =3D true" to current FWFT, because KVM can't be changing the SEE for userspace. Do you want me to send a patch that inverts the default, to make all future SBI extension start as disabled, so we can't easily repeat the mistake in the future? Thanks.