On Wed, Jul 24, 2024, Maxim Levitsky wrote:
> On Mon, 2024-07-08 at 15:30 -0700, Sean Christopherson wrote:
> > On Thu, Jul 04, 2024, Maxim Levitsky wrote:
> > > On Fri, 2024-05-17 at 10:39 -0700, Sean Christopherson wrote:
> > > There are several advantages to this:
> > >
> > > - more readability, plus if needed each statement can be amended with a comment.
> > > - No weird hacks in 'F*' macros, which additionally eventually evaluate into a bit,
> > > which is confusing.
> > > In fact no need to even have them at all.
> > > - No need to verify that bitmask belongs to a feature word.
> >
> > Yes, but the downside is that there is no enforcement of features in a word being
> > bundled together.
>
> As I explained earlier, this is not an issue in principle, even if the caps are not
> grouped together, the code will still work just fine.
I agree that functionally it'll all be fine, but I also want the code to bunch
things together for readers. We can force that with functions, though it means
passing in more state to kvm_cpu_cap_init_{begin,end}().
> kvm_cpu_cap_init_begin(CPUID_1_ECX);
> /* TMA is not passed though because: xyz*/
> kvm_cpu_cap_init(TMA, 0);
> kvm_cpu_cap_init(SSSE3, CAP_PASSTHOUGH);
> /* CNXT_ID is not passed though because: xyz*/
> kvm_cpu_cap_init(CNXT_ID, 0);
> kvm_cpu_cap_init(RESERVED, 0);
> kvm_cpu_cap_init(FMA, CAP_PASSTHOUGH);
> ...
> /* KVM always emulates TSC_ADJUST */
> kvm_cpu_cap_init(TSC_ADJUST, CAP_EMULATED | CAP_SCATTERED);
>
> kvm_cpu_cap_init_end(CPUID_1_ECX);
>
> ...
>
> ...
>
> And kvm_cpu_cap_init_begin, can set some cap_in_progress variable.
Ya, but then compile-time asserts become run-time asserts.
> > > - Merge friendly - each capability has its own line.
> >
> > That's almost entirely convention though. Other than inertia, nothing is stopping
> > us from doing:
> >
> > kvm_cpu_cap_init(CPUID_12_EAX,
> > SF(SGX1) |
> > SF(SGX2) |
> > SF(SGX_EDECCSSA)
>
> That trivial change is already an improvement, although it still leaves the problem
> of thinking that this is one bit 'or', which was reasonable before this patch series,
> because it was indeed one big 'or' but now there is lots of things going on behind
> the scenes and that violates the principle of the least surprise.
>
> My suggestion fixes this, because when the user sees a series of function calls,
> and nobody will assume anything about these functions calls in contrast with series
> of 'ors'. It's just how I look at it.
If it's the macro styling that's misleading, we could do what we did for the
static_call() wrappers and make them look like functions. E.g.
kvm_cpu_cap_init(CPUID_12_EAX,
scattered_f(SGX1) |
scattered_f(SGX2) |
scattered_f(SGX_EDECCSSA)
);
though that probably doesn't help much and is misleading in its own right. Does
it help if the names are more verbose?
> > );
> >
> > I don't see a clean way of avoiding the addition of " |" on the last existing
> > line, but in practice I highly doubt that will ever be a source of meaningful pain.
> >
> > Same goes for the point about adding comments. We could do that with either
> > approach, we just don't do so today.
>
> Yes, from the syntax POV there is indeed no problem, and I do agree that putting
> each feature on its own line, together with comments for the features that need it
> is a win-win improvement over what we have after this patch series.
>
> >
> > > Disadvantages:
> > >
> > > - Longer list - IMHO not a problem, since it is very easy to read / search
> > > and can have as much comments as needed.
> > > For example this is how the kernel lists the CPUID features and this list IMHO
> > > is very manageable.
> >
> > There's one big difference: KVM would need to have a line for every feature that
> > KVM _doesn't_ support.
>
> Could you elaborate on why?
> If we zero the whole leaf and then set specific bits there, one bit per kvm_cpu_cap_init.
Ah, if we move the the handling of boot_cpu_data[*] into the helpers, then yes,
there's no need to explicitly initialize features that aren't supported by KVM.
That said, I still don't like using functions instead of macros, mainly because
a number of compile-assertions become run-time assertions. To provide equivalent
functionality, we also would need to pass in extra state to begin/end() (as
mentioned earlier). Getting compile-time assertions on usage, e.g. via
guest_cpu_cap_has(), would also be trickier, though still doable, I think.
Lastly, it adds an extra step (calling _end()) to each flow, i.e. adds one more
thing for developers to mess up. But that's a very minor concern and definitely
not a sticking point.
I agree that the macro shenanigans are aggressively clever, but for me, the
benefits of compile-time asserts make it worth dealing with the cleverness.
[*] https://lore.kernel.org/all/ZqKlDC11gItH1uj9@xxxxxxxxxx
