On Mon, Feb 04, 2019 at 02:14:30PM -0800, Fenghua Yu wrote:
> With "setcpuid=", there is no additional code to add as long as
> enumeration code is available.
Wait, are you saying that all the other enablement of new features is
easy and the only problem is patching {early_,}init_intel() so you'd
prefer not to patch it each time and use a cmdline param instead which
is error prone and really user-unfriendly?!
Usually, the patch adding the CPUID flag and checking is the easiest
one.
Also, you do realize that even if it gets applied, it will need
to sanity-check everything passed in, which means, it will accept
*only* the leafs which you guys don't have in CPUID?! It won't be a
lets-enable-this-random-cpuid-bits-and-see-what-happens deal.
Because I don't think anyone will be willing to debug reports from such
random enablements. The qemu+kvm "experiments" are already painful
enough.
By then you're better off simply patching {early_,}init_intel() I'd say.
> Every time a new feature like this case, the early_init_intel() needs
> to be changed for FMS etc.
Yes, as part of the enablement. You really seldomly - if ever at all -
have a new feature which only needs CPUID enablement. Unless it is some
feature flag to show support for new insns but that gets applied almost
immediately and I doubt userspace even uses it through /proc/cpuinfo -
they do their own querying of CPUID.
Because if they do the latter, setcpuid= will give you nothing unless we
enforce CPUID faulting. Except *that* is not present everywhere...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
