Re: [PATCH v21 05/23] KVM: arm64: Track the type of VM in kvm_arch

[Marc Zyngier]

On Sat, 03 Oct 2026 08:07:39 +0100,
Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
> 
> 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 <tabba@xxxxxxxxxx> wrote:
> >>> 
> >>> Hi Marc,
> >>> 
> >>> On Fri, 02 Oct 2026 15:15:06 +0100, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >>> [...]
> >>>> 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:
> >>>> 
> >>>>          if (vcpu->kvm->arch.vm_flavor != VM_PROTECTED_PKVM)
> >>>>                  return;
> >>> 
> >>> 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 != VM_PKVM.
> >> 
> >> See what I meant about this stuff being completely intractable? I
> >> still have no idea what it means! ;-)
> >> 
> > 
> > Just to be clear: unprotected_pkvm() != (vm_flavor != VM_PROTECED_PKVM).
> > Rather, unprotected_pkvm => (vm_flavor == VM_PKVM).
> > 
> > And the code wanted to bail out early for !unprotected_pkvm(). We can
> > stick in "is_protected_kvm_enabled()" for unprotected_pkvm predicate
> > 
> > But, I can drop the helper and use the vm_flavor check.
> 
> 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.

-- 
Without deviation from the norm, progress is not possible.