Thread (152 messages) 152 messages, 8 authors, 2020-06-12

Re: [PATCH v3 64/75] x86/sev-es: Cache CPUID results for improved performance

From: Borislav Petkov <bp@alien8.de>
Date: 2020-05-26 09:19:18
Also in: kvm, lkml

On Tue, May 19, 2020 at 10:16:37PM -0700, Sean Christopherson wrote:
The whole cache on-demand approach seems like overkill.  The number of CPUID
leaves that are invoked after boot with any regularity can probably be counted
on one hand.   IIRC glibc invokes CPUID to gather TLB/cache info, XCR0-based
features, and one or two other leafs.  A statically sized global array that's
arbitrarily index a la x86_capability would be just as simple and more
performant.  It would also allow fancier things like emulating CPUID 0xD in
the guest if you want to go down that road.
And before we do any of that "caching" or whatnot, I'd like to see
numbers justifying its existence. Because if it is only a couple of
CPUID invocations and the boot delay is immeasurable, then it's not
worth the effort.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help