Messages in this thread | | | Date | Tue, 5 Feb 2019 07:10:26 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid |
| |
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.
| |