Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Mon, 14 Mar 2022 12:06:53 +0100
From:   Andrew Jones <drjones@redhat.com>
To:     Sean Christopherson <seanjc@google.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, Thomas Huth <thuth@redhat.com>,
        Janosch Frank <frankja@linux.ibm.com>,
        Claudio Imbrenda <imbrenda@linux.ibm.com>,
        David Hildenbrand <david@redhat.com>,
        David Matlack <dmatlack@google.com>,
        Ben Gardon <bgardon@google.com>,
        Oliver Upton <oupton@google.com>
Subject: Re: [RFC PATCH 000/105] KVM: selftests: Overhaul APIs, purge VCPU_ID
Message-ID: <20220314110653.a46vy5hqegt75wpb@gator>
References: <20220311055056.57265-1-seanjc@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220311055056.57265-1-seanjc@google.com>
Precedence: bulk

On Fri, Mar 11, 2022 at 05:49:11AM +0000, Sean Christopherson wrote:
> First off, hopefully I didn't just spam you with 106 emails.  In theory,
> unless you're subscribed to LKML, you should see only the cover letter
> and everything else should be on lore if you want to pull down the mbox
> (instead of saying "LOL, 105 patches!?!?", or maybe after you say that).
> 
> This is a (very) early RFC for overhauling KVM's selftests APIs.  It's
> compile tested only (maybe), there are no changelogs, etc...
> 
> My end goal with an overhaul is to get to a state where adding new
> features and writing tests is less painful/disgusting (I feel dirty every
> time I copy+paste VCPU_ID).  I opted to directly send only the cover
> letter because most of the individual patches aren't all that interesting,
> there's still 46 patches even if the per-test conversions are omitted, and
> it's the final state that I really care about and want to discuss.
> 
> The overarching theme of my take on where to go with selftests is to stop
> treating tests like second class citizens.  Stop hiding vcpu, kvm_vm, etc...
> There's no sensitive data/constructs, and the encapsulation has led to
> really, really bad and difficult to maintain code.  E.g. Want to call a
> vCPU ioctl()?  Hope you have the VM...

Ack to dropping the privateness of structs.

> 
> The other theme in the rework is to deduplicate code and try to set us
> up for success in the future.  E.g. provide macros/helpers instead of
> spamming CTRL-C => CTRL-V (see the -700 LoC).

Ack to more helper functions. I'm not sure what the best way to document
or provide examples for the API is though. Currently we mostly rely on
test writers to read other tests (I suppose the function headers help a
bit, but, IMO, not much). Maybe we need a heavily commented example.c
that can help test writers get started, along with better API function
descriptions for anything exported from the lib.

> 
> I was hoping to get this into a less shabby state before posting, but I'm
> I'm going to be OOO for the next few weeks and want to get the ball rolling
> instead of waiting another month or so.

Ideas look good to me, but I'll wait for the cleaned up series posted to
the KVM ML to review it. Also, I see at least patch 1/105 is a fix. It'd
be nice to post all fixes separately so they get in sooner than later.

Oh, some of the renaming doesn't look all that important to me, like
prefixing with kvm_ or adding _arch_, but I don't have strong preferences
on the names. Also, for the _arch_ functions it'd be nice to create
common, weak functions which the arch must override. The common function
would just assert. That should help people who want to port to other
architectures determine what they need to implement first. And, for
anything which an arch can optionally adopt a common implementation,
*not* naming the common function with _arch_, but still defining it as
weak, would make sense to me too.

Thanks,
drew