Re: [PATCH v1 0/4] KVM: arm64: Update KVM_VCPU_MAX_FEATURES and refactor to avoid same issue

[Marc Zyngier <maz@kernel.org>]

On Mon, 14 Oct 2024 19:17:19 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Marc,
> 
> On Mon, 14 Oct 2024 at 18:17, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Mon, 14 Oct 2024 17:58:05 +0100,
> > Fuad Tabba <tabba@google.com> wrote:
> > >
> > > The value of KVM_VCPU_MAX_FEATURES has not been updated since
> > > adding new features in commit 89b0e7de3451 ("KVM: arm64: nv:
> > > Introduce nested virtualization VCPU feature").
> >
> > Could you please expand on what is broken? 89b0e7de3451 makes a point
> > in *not* exposing this to userspace, as outlined in the commit
> > message -- this is done on purpose, because NV is not functional yet.
> 
> I understand. I was wondering how you would test NV when this feature

Testing????? Fool!!! KVM is a *write-only* code base.

More seriously, we have zillions of out-of-tree patches that actually
enable the thing, just like for pKVM.

> isn't settable, which is why I thought it was broken. That said, maybe
> a comment by the definition of KVM_VCPU_MAX_FEATURES to that effect
> might make things less confusing for people like me :)
> 
> With that, is it worth repinning this patch, or is it not worth the
> complexity of trying to hide NV as long as it's not supported?

Maybe that's the sort of kick up the bum I need to actually enable
*some* NV support upstream.

Let me see if I can extract something from the current mess.

	M.

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