Adding host cpu info.

# lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              32
On-line CPU(s) list: 0-31
Thread(s) per core:  2
Core(s) per socket:  8
Socket(s):           2
NUMA node(s):        8
Vendor ID:           AuthenticAMD
CPU family:          23
Model:               1
Model name:          AMD EPYC 7251 8-Core Processor
Stepping:            2
CPU MHz:             2324.271
CPU max MHz:         2100.0000
CPU min MHz:         1200.0000
BogoMIPS:            4191.53
Virtualization:      AMD-V
L1d cache:           32K
L1i cache:           64K
L2 cache:            512K
L3 cache:            4096K
NUMA node0 CPU(s):   0,1,16,17
NUMA node1 CPU(s):   2,3,18,19
NUMA node2 CPU(s):   4,5,20,21
NUMA node3 CPU(s):   6,7,22,23
NUMA node4 CPU(s):   8,9,24,25
NUMA node5 CPU(s):   10,11,26,27
NUMA node6 CPU(s):   12,13,28,29
NUMA node7 CPU(s):   14,15,30,31
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

I found the comment in cpu.c.

        /*                                                                      
         * TOPOEXT is always allowed but can't be enabled blindly by                                  
         * "-cpu host", as it requires consistent cache topology info           
         * to be provided so it doesn't confuse guests.                         
         */                                                                     
        .no_autoenable_flags = CPUID_EXT3_TOPOEXT, 

So it's expected that no topoext flag in guest in this case. 

The left question is, is arch_capabilities expected to be in guest? If so, I will close this bug. Thanks.

Hi Eduardo,

Could you please tell if it is expected that arch_capabilities can be exposed to guest though host doesn't have the flag? E.g. 1) Boot guest with '-cpu host' on EPYC host or Haswell host, 2)Boot guest with '-cpu ModelName,+arch-capabilities' on any host, flag arch_capabilities is in guest.

I only see the flag in Coffeelake and Cascadelake host. Does the flag 'arch-capabilities' in QEMU have nothing to do with the flag 'arch_capabilities' in host, and we can turn it on with any CPU model on any host? If so, it's not necessary to verify bugs like 1709993, only on Cascadelake host, other hosts should fit too, right ?

(In reply to Yumei Huang from comment #5)

It is possible to emulate the arch-capabilities MSR on any Intel host (it shouldn't be possible on AMD hosts).  But in order to validate the bug you need a host that has the MSR available, so you can compare vulnerability info provided by the host with vulnerability info seen by the guest.

(In reply to Eduardo Habkost from comment #6)
> (In reply to Yumei Huang from comment #5)
> 
> It is possible to emulate the arch-capabilities MSR on any Intel host (it
> shouldn't be possible on AMD hosts).  

So is it something to be fixed that '-cpu host' on amd host and '-cpu EPYC,+arch-capabilities' would expose arch_capabilities to guest ? If so, I will file a new bug, thanks!

(In reply to Yumei Huang from comment #7)
> (In reply to Eduardo Habkost from comment #6)
> > (In reply to Yumei Huang from comment #5)
> > 
> > It is possible to emulate the arch-capabilities MSR on any Intel host (it
> > shouldn't be possible on AMD hosts).  
> 
> So is it something to be fixed that '-cpu host' on amd host and '-cpu
> EPYC,+arch-capabilities' would expose arch_capabilities to guest ? If so, I
> will file a new bug, thanks!

Being able to emulate it on AMD is not a bug, it was just a limitation of KVM, until the following upstream commit (backport included in kernel-4.18.0-97.el8).  After the commit below, emulation of MSR_IA32_ARCH_CAPABILITIES is possible on AMD CPUs.

It's important to check if guests won't crash if arch-capabilities is enabled on AMD hosts, though.  We had some bugs in the arch-capabilities CPUID and MSR code in the past.


commit 0cf9135b773bf32fba9dd8e6699c1b331ee4b749
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Mar 7 15:43:02 2019 -0800

    KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts
    
    The CPUID flag ARCH_CAPABILITIES is unconditioinally exposed to host
    userspace for all x86 hosts, i.e. KVM advertises ARCH_CAPABILITIES
    regardless of hardware support under the pretense that KVM fully
    emulates MSR_IA32_ARCH_CAPABILITIES.  Unfortunately, only VMX hosts
    handle accesses to MSR_IA32_ARCH_CAPABILITIES (despite KVM_GET_MSRS
    also reporting MSR_IA32_ARCH_CAPABILITIES for all hosts).
    
    Move the MSR_IA32_ARCH_CAPABILITIES handling to common x86 code so
    that it's emulated on AMD hosts.
    
    Fixes: 1eaafe91a0df4 ("kvm: x86: IA32_ARCH_CAPABILITIES is always supported")
    Cc: stable@vger.kernel.org
    Reported-by: Xiaoyao Li <xiaoyao.li@linux.intel.com>
    Cc: Jim Mattson <jmattson@google.com>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Setting FutureFeature, as "-cpu host" support for TOPOEXT isn't implemented upstream.

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks