From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A6757C3DA4A for ; Thu, 8 Aug 2024 18:32:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MCEvSa1rci8lOZvwzCzc6u9Pm8Tp4sCjT5NtOCzDNF0=; b=HJWdq6uwPEWS8cSo0uhxs05eIP gTOWb4rn2a2md8kqXXBhWPcIp24zpNYHJpgUh1ZxlNga4oGRgE+G2Mc6WYCBu43OdTOa5RRMxQisk GKnXB/8OAgG8ClF4xupPwWDRceKF6+WsH5bj7ix1sf1mHo+xUg/60q06QB1gn9OUSc2Mzc4Kt2oOl mJ6Em1WTygG+swaSy8IGWN2gkGie22lIn9OqisPJVYC0TyOiK7iBLiGcrp/iUwFghyWd5GqiHpGNF TEwt1305hSKE6nmjm2tgXzgpaMBBRrN3cOpUiWkLcKRFgVmzVKpv4fm3s5lN15oioWgsVWAO0aRvs Gwxse4Jg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sc7vm-00000009Cvs-2oGK; Thu, 08 Aug 2024 18:32:10 +0000 Received: from out-170.mta1.migadu.com ([2001:41d0:203:375::aa]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sc7vC-00000009Cqz-1Oz1 for linux-arm-kernel@lists.infradead.org; Thu, 08 Aug 2024 18:31:36 +0000 Date: Thu, 8 Aug 2024 18:31:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1723141890; 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: in-reply-to:in-reply-to:references:references; bh=MCEvSa1rci8lOZvwzCzc6u9Pm8Tp4sCjT5NtOCzDNF0=; b=P35qKX3jpcNrEiDjJ3mJ+K9wSyV6ibp3BE01cQLuPeHycT2wFJnnUtA+olTGhaHhLD2HR8 PzCBUBbmj1+FZn68ZBJHSkg5Waj9XWqj9eMVh7pqoemZ5fwbGxmK5ptAF20yQ2LxCFO3L5 Z9GcCxjDnHpDebH+qgA3uocWlvwJ3aQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Shameerali Kolothum Thodi Cc: "kvmarm@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "maz@kernel.org" , "will@kernel.org" , "catalin.marinas@arm.com" , "james.morse@arm.com" , "suzuki.poulose@arm.com" , yuzenghui , "Wangzhou (B)" , Linuxarm Subject: Re: [PATCH] KVM: arm64: Disable OS double lock visibility by default and ignore VMM writes Message-ID: References: <20240808125711.14368-1-shameerali.kolothum.thodi@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240808_113134_731981_AD3E85FE X-CRM114-Status: GOOD ( 34.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 08, 2024 at 06:10:33PM +0000, Shameerali Kolothum Thodi wrote: > > I find myself asking *why* we need this, could you share some details > > on the issue you're encountering? > > Sorry, I missed the why part. Mainly for VM migration purposes as we have systems > with DoubleLock implemented and not implemented(with DebugVer 8.2). Ah, got it, thanks for the context. > > > > Indeed, RAZ/WI is not a faithful implementation of FEAT_DoubleLock, but > > I wouldn't expect it to be used in a VM in the first place. > > > > On Thu, Aug 08, 2024 at 01:57:11PM +0100, Shameer Kolothum wrote: > > > KVM exposes the OS double lock feature bit to Guests but returns > > > RAZ/WI on Guest OSDLR_EL1 access. Make sure we are hiding OS double > > > lock from Guests now. However we can't hide DoubleLock if the reported > > > DebugVer is < 8.2. So report a minimum DebugVer of 8.2 to Guests. > > > > What if a user wanted to virtualize an exact CPU model that only > > implemented v8.0? > > Yeah. I was a bit concerned as mentioned below of bumping up DebugVer to 8.2. > But then I found a similar attempt you made a while back, > https://lore.kernel.org/linux-arm-kernel/20211029003202.158161-1-oupton@google.com/T/#meee94d87db3f8042156557dbf9743bb03cf0aaa9 Using my own crap patches against me, drat! :-) In all seriousness, this has since been resolved with the 'writable' ID register infrastructure and corresponding changes raising the max possible debug arch to v8.8. DebugVer will match the HW value up to v8.8, but userspace can 'downgrade' the feature by writing a lesser value. So in the case of cross-system migration, the old value is still accepted by KVM + advertised to the VM. > > > > > All this may break migration from the older kernels. Take care of > > > that by ignoring VMM writes for these values. > > > > Ignoring userspace writes is a pretty big hammer. In situations where > > KVM had advertised a feature that was outright not supported (e.g. IMP DEF > > PMUs) it _might_ make sense. But with this change we're messing with a > > CPU feature we *do* support. > > The concern here is for the DebugVer I guess. Indeed. > But if VMs are not making use of any 8.0 specific features(as I understand it, > only external debugger support is the difference), then is that an issue? You're absolutely right to point out that v8.0 -> v8.2 doesn't change anything from the VM's POV. My concern is that the guest does not anticipate ID registers changing values at runtime, and we should only reach for that big hammer if we (KVM) have done something truly stupid. Which never happens, of course :) > > Would allowing userspace to downgrade ID_AA664DFR0_EL1.DoubleLock to > > 0b1111 be enough? > > Yeah. Could I guess. But then we need to check the DebugVer matches to 8.2 or not > as well. Eh, I don't think that KVM needs to be policing the VMM for total compliance with the architecture. What's far more important is guaranteeing the selected CPU feature set is a subset of what KVM virtualizes. So even though the architecture says !FEAT_DoubleLock && !FEAT_Debugv8p2 is not allowed, it isn't a problematic configuration for KVM. Still, the defaults from KVM should still comply with the architecture as closely as possible. > Idea was, is there any point in exposing features that are not supported or used > by VMs in the first place. And I generally agree, but the need to churn other fields to get to a sane starting point gave me a bit of pause. Would you be willing to cook up a patch that just opens up the DoubleLock field to downgrades? -- Thanks, Oliver