From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 A700DEEB3; Sat, 3 Oct 2026 08:45:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791017152; cv=none; b=cWXxv+X1Kt6ls4AaXXedNwTZHlx8bzb9aRxJWhnduLcEuVUzClKX5rDhgEAp24oiFSYHLzxoEt2J3unKq5LUxXUqvAMK3Mt4ZGFxu7dfyeNVnqI303AVEDYb2Sz3/DbE9vItlNnsm1S7OA4LPD1xx8+CDvYObXnKlBaNBmMoY3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791017152; c=relaxed/simple; bh=a0nX+tv2G5b7HuoiyPpcU5xklgUpccGz4acc0Y+2SaA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=F/AI8Endy/D5O3siE6kpeARjyNZD5pgGFQI3IxoSUAZyQV80uRpqt+TWWgbii+mBy3M+5ervYg5IuuSZGTAfh4vb4yxBXS3bOST4JpjGmCHAyQKjRH+2rMV+lhkanmmgfbfFiMx0Vv/TdMd5mIDMWrjhOqrXS1SfFm++ERGrctM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CdvyVKHZ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CdvyVKHZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37BA01F0089B; Sat, 3 Oct 2026 08:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791017151; bh=zxZleFQUEISD064kSfjMjMxf0Adv0+eg+SUInoyeOkM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=CdvyVKHZynq+wKXiwTb2wUbImBUsPXNZ9b5G58qvJbwUraRUEMQLg1XT9zBpaQtHz O/sZaA5oyo2yoo8B9GvO+5BtRoTLEMHSJ04cG3FJzBxIui+zMCpHs5wSxYRvUwFBPg mvJVCepy0Nk8CjWXTZZULFrfKzGqsoAQXWQoYLGx7OgBxI09TfXciGLJabnWopj8Kx Ir6c7ZIBqhhxqfiASq5aVX/zimjZTCZklH/GhBmcHMq1l088jV2lnTsWgytwLGwJ1r FRfWOPfhhHOs3Awk9IHTDr6kVRfPhWKAq5xq3PbUbmyg53/ZEKZqNh9cv78oWKlkHo oaPfn7JY5t+4w== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCvNM-0000000GUTq-3GbA; Sat, 03 Oct 2026 08:45:48 +0000 Date: Sat, 03 Oct 2026 09:45:48 +0100 Message-ID: <86jynz2mv7.wl-maz@kernel.org> From: Marc Zyngier To: Suzuki K Poulose Cc: Fuad Tabba , kvm@vger.kernel.org, kvmarm@lists.linux.dev, will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, steven.price@arm.com, aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com, joey.gouly@arm.com, yuzenghui@huawei.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, sdonthineni@nvidia.com, alpergun@google.com, fj0570is@fujitsu.com, WeiLin.Chang@arm.com, lpieralisi@kernel.org, enju.kohei@fujitsu.com, sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com Subject: Re: [PATCH v21 05/23] KVM: arm64: Track the type of VM in kvm_arch In-Reply-To: References: <20261001210703.1597150-1-suzuki.poulose@arm.com> <20261001210703.1597150-6-suzuki.poulose@arm.com> <86se2o2rbs.wl-maz@kernel.org> <86pkxs2npx.wl-maz@kernel.org> <86o6dc2ka1.wl-maz@kernel.org> <83e79119-b331-4640-b2c7-cc8135d71c77@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: suzuki.poulose@arm.com, tabba@google.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, steven.price@arm.com, aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com, joey.gouly@arm.com, yuzenghui@huawei.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, sdonthineni@nvidia.com, alpergun@google.com, fj0570is@fujitsu.com, WeiLin.Chang@arm.com, lpieralisi@kernel.org, enju.kohei@fujitsu.com, sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sat, 03 Oct 2026 08:07:39 +0100, Suzuki K Poulose wrote: >=20 > On 03/10/2026 06:53, Suzuki K Poulose wrote: > > On 02/10/2026 16:29, Marc Zyngier wrote: > >> On Fri, 02 Oct 2026 15:37:00 +0100, > >> Fuad Tabba wrote: > >>>=20 > >>> Hi Marc, > >>>=20 > >>> On Fri, 02 Oct 2026 15:15:06 +0100, Marc Zyngier wro= te: > >>> [...] > >>>> Honestly, we introduce the flavor stuff to make it easy to match > >>>> things on a particular VM type in a readable way. So why isn't this > >>>> reading: > >>>>=20 > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (vcpu->kvm->arch= .vm_flavor !=3D VM_PROTECTED_PKVM) > >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return; > >>>=20 > >>> I know this is a sketch, but just in case: that's inverted. The sync > >>> only applies to non-protected pKVM VMs (EL2 ignores it for protected > >>> ones), so it would be !=3D VM_PKVM. > >>=20 > >> See what I meant about this stuff being completely intractable? I > >> still have no idea what it means! ;-) > >>=20 > >=20 > > Just to be clear: unprotected_pkvm() !=3D (vm_flavor !=3D VM_PROTECED_P= KVM). > > Rather, unprotected_pkvm =3D> (vm_flavor =3D=3D VM_PKVM). > >=20 > > And the code wanted to bail out early for !unprotected_pkvm(). We can > > stick in "is_protected_kvm_enabled()" for unprotected_pkvm predicate > >=20 > > But, I can drop the helper and use the vm_flavor check. >=20 > FWIW: Here is the diff for the above change. If you are happy > with the following, I could fold this in. Yes please. This is far more readable. Once we have the full picture, we can maybe look at more synthetic helpers, but let's start without any premature abstraction. Thanks, M. --=20 Without deviation from the norm, progress is not possible.