From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7233299920; Fri, 23 May 2025 18:02:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748023352; cv=none; b=TpP8hCaF2WCdXgRr4nZ2l1fCWGWDj/kLdBmJ2qSTXYmslxu1M2qdxNH1SBB4PdKqUQC994GB6R1IgJRQlD7aLY01ElEYxhixj5P4N96yKWsU10VXOY7n+wunhnvUlLC6BT79XbQ/BtBu9bTWoW1C5JXSTkGVUfAAsByroD41P80= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748023352; c=relaxed/simple; bh=/IJS+eg31HVMWiLhSeRqgdbO7HyM9IVVNSvfwS9h97Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gKxNQWPp9hV8QDOH00vDhXY4R6hikwKLLuaL05MtOh3nW1ZnWjFRBfTA8OCgVwcv6pRMxBRjUlAF8GdvMlBgsuj1nXBkz0XcHAmzQG03+LTgoAdSEuiZPWLdZovpyOO3eeibxn0pGIOlEtNdvhx/5DviIhfvhljGJbnq12U95kE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=cb6ir8xE; arc=none smtp.client-ip=91.218.175.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="cb6ir8xE" Message-ID: <5dd587b3-8c04-41d1-b677-5b07266cfec5@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748023337; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dVgfGwkpVOgVzuNCU5zCPpN93of0x7k+aYCz5DP0VOA=; b=cb6ir8xE4q8LN9CRbizpHOwYHG/1HnOlKRh3ajaE1tDkmTd8L19cu4lPf8tqbFVowAvU7o 37f+G4WGNnNmva62kOAHzlLog/TeUa+vG94ciSfJV4Agz/wUc+d1DCUpdSbMrQe4M9rbRz +MQCdF0ERsqq1cCkeU0V+ucqdayBGaM= Date: Fri, 23 May 2025 11:02:11 -0700 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v8 13/14] RISC-V: KVM: add support for FWFT SBI extension To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Paul Walmsley , Palmer Dabbelt , Anup Patel , Atish Patra , Shuah Khan , Jonathan Corbet , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-kselftest@vger.kernel.org Cc: Samuel Holland , Andrew Jones , Deepak Gupta , Charlie Jenkins , linux-riscv References: <20250523101932.1594077-1-cleger@rivosinc.com> <20250523101932.1594077-14-cleger@rivosinc.com> <9f9e2869-725d-4590-887a-9b0ef091472e@rivosinc.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Atish Patra In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 5/23/25 9:27 AM, Radim KrÄmáŠwrote: > 2025-05-23T17:29:49+02:00, Clément Léger : >> On 23/05/2025 15:05, Radim Krčmář wrote: >>> 2025-05-23T12:19:30+02:00, Clément Léger : >>>> +++ b/arch/riscv/kvm/vcpu_sbi_fwft.c >>>> +static const enum sbi_fwft_feature_t kvm_fwft_defined_features[] = { >>>> + SBI_FWFT_MISALIGNED_EXC_DELEG, >>>> + SBI_FWFT_LANDING_PAD, >>>> + SBI_FWFT_SHADOW_STACK, >>>> + SBI_FWFT_DOUBLE_TRAP, >>>> + SBI_FWFT_PTE_AD_HW_UPDATING, >>>> + SBI_FWFT_POINTER_MASKING_PMLEN, >>>> +}; >>> >>> How will userspace control which subset of these features is allowed in >>> the guest? >>> >>> (We can reuse the KVM SBI extension interface if we don't want to add a >>> FWFT specific ONE_REG.) >> >> Hi Radim, >> >> I didn't looked at that part. But most likely using the kvm one reg >> interface seems ok like what is done for STA ? We could have per feature >> override with one reg per feature. > > Sounds fine. > Yeah. We can have a follow up series for SBI FWFT state that allows user space to toggle each state individually. >> Is this something blocking though ? We'd like to merge FWFT once SBI 3.0 >> is ratified so that would be nice not delaying it too much. I'll take a >> look at it to see if it isn't too long to implement. > > Not blocking, but I would at least default FWFT to disabled, because > current userspace cannot handle [14/14]. (Well... save/restore was > probably broken even before, but let's try to not make it worse. :]) > User space can not enable or disable misaligned access delegation as there is no interface for now rightly pointed by you. I guess supporting that would be quicker than fixing the broader guest save/restore anyways. Isn't it ? We can have the patches ready for the next MW for FWFT one reg interface. > Thanks. > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv