On 26/11/2025 4:44 pm, Alejandro Vallejo wrote: > Just knowing x86_vendor_is() is "good to have" is good enough as it enables > our > downstream to customise it with whatever optimisations we need. > > I also suspect other areas of the hypervisor could benefit from this meld of > runtime+compiletime sort of checking, allowing transparent code removal. > > I'm thinking DOM0LESS_BOOT vs DOM0_BOOT vs PVSHIM_BOOT, or AMD_SVM vs > INTEL_VMX > in HVM-only builds, or family checks to have (i.e) a explicit "older-than-zen" > Kconfig option with a similar approach on a family range check. > > This is maybe one of several such uses. > > So... thoughts? I'm definitely fond of the single-vendor bloat-o-meter output.
Having looked through the whole series, I'm not a massive fan of converting the switch() statements, but it's the only way to do the DCE. So be it. I think x86_vendor_is(var, MASK) wants to become boot_vendor(MASK). Most cases want the boot vendor, and those that appear to want something else don't actually. When you disable the cross-vendor case (patch 2 pulled out ahead), then cp->vendor == boot_vendor and then you don't need a variable to pass in. This also reduces the verbosity of the new lines which is an improvement. That said, this series also collides substantially with the Intel Fam 18/19 work, which is more urgent and needs backporting to 4.21. More specifically, there are a bunch of changes which interfere with VFM conversion, and for which I can't see an obvious DCE reason to have, so I'm wondering if they were just part of "convert everything". ~Andrew
