Bug 1738775 - QEMU should report mds-no as enabled in query-cpu-model-expansion
Summary: QEMU should report mds-no as enabled in query-cpu-model-expansion
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Eduardo Habkost
QA Contact: Yumei Huang
URL:
Whiteboard:
Depends On: 1738773
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-08 06:48 UTC by Yumei Huang
Modified: 2019-09-03 02:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1738773
Environment:
Last Closed: 2019-09-03 02:59:23 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Yumei Huang 2019-08-08 06:48:20 UTC
Cloned for slow train. 

Version:
qemu-kvm-2.12.0-83.module+el8.1.0+3852+0ba8aef0

+++ This bug was initially created as a clone of Bug #1738773 +++

Description of problem:
QEMU report mds-no as false in query-cpu-model-expansion, causing no mds-no for 'host-model' on Cascadelake host. 

Version-Release number of selected component (if applicable):
qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3
libvirt-client-5.5.0-2.module+el8.1.0+3773+7dd501bf.x86_64
kernel-4.18.0-124.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1. Start qemu, query cpu model expansion
{ "execute":"query-cpu-model-expansion","arguments":{"type":"full","model":{"name":"Cascadelake-Server"}}}

2. Run virsh domcapabilities
# virsh domcapabilities

3.

Actual results:
{ "execute":"query-cpu-model-expansion","arguments":{"type":"full","model":{"name":"Cascadelake-Server"}}}
{"return": {"model": {"name": "Cascadelake-Server", "props": {"phys-bits": 0,...,"mds-no": false,..."xstore-en": false}}}}

# virsh domcapabilities
 <mode name='host-model' supported='yes'>
      <model fallback='forbid'>Cascadelake-Server</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='vmx'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='umip'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='xsaves'/>
      <feature policy='require' name='invtsc'/>
    </mode>

Expected results:
mds-no is reported as enabled.

Additional info:

Comment 2 Eduardo Habkost 2019-08-30 21:05:04 UTC
(In reply to Yumei Huang from comment #0)
> Expected results:
> mds-no is reported as enabled.

Why is this the expected result?  Do you have /proc/cpuinfo and /sys/devices/system/cpu/vulnerabilities/mds contents for the host?

Comment 3 Eduardo Habkost 2019-08-30 21:07:38 UTC
I can't reproduce it.  On a host I'm using, mds-no is reported as true.

# rpm -q qemu-kvm
qemu-kvm-2.12.0-85.module+el8.1.0+4010+d6842f29.x86_64
# ps ax | grep qemu
31299 pts/2    Sl+    0:00 /usr/libexec/qemu-kvm -machine accel=kvm -qmp unix:/tmp/qmp,server
31303 pts/1    R+     0:00 grep --color=auto qemu
# echo 'query-cpu-model-expansion type=full model={"name":"host"}' | python2 ./scripts/qmp/qmp-shell -p /tmp/qmp | egrep 'rdctl-no|ibrs-all|rsba|skip-l1dfl-vmentry|ssb-no|mds-no'
                "mds-no": true, 
                "rdctl-no": true, 
                "ssb-no": false, 
                "ibrs-all": true, 
                "skip-l1dfl-vmentry": true, 
                "rsba": false, 
#

Comment 5 Eduardo Habkost 2019-08-30 21:15:40 UTC
For reference, MDS_NO will be set only on the CPUs listed with "No" in all 3 columns at:
https://software.intel.com/security-software-guidance/insights/deep-dive-cpuid-enumeration-and-architectural-msrs#MDS-CPUID

Comment 6 Yumei Huang 2019-08-31 13:36:39 UTC
(In reply to Eduardo Habkost from comment #2)
> (In reply to Yumei Huang from comment #0)
> > Expected results:
> > mds-no is reported as enabled.
> 
> Why is this the expected result?  Do you have /proc/cpuinfo and
> /sys/devices/system/cpu/vulnerabilities/mds contents for the host?

I thought only when it's reported as enabled, it would be in virsh domcapabilities, then it will be exposed to guest when use host-model. Did I get it wrong?

Host info:

# lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              192
On-line CPU(s) list: 0-191
Thread(s) per core:  2
Core(s) per socket:  24
Socket(s):           4
NUMA node(s):        4
Vendor ID:           GenuineIntel
CPU family:          6
Model:               85
Model name:          Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz
Stepping:            7
CPU MHz:             3264.469
CPU max MHz:         3800.0000
CPU min MHz:         1000.0000
BogoMIPS:            4600.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            1024K
L3 cache:            36608K
NUMA node0 CPU(s):   0-23,96-119
NUMA node1 CPU(s):   24-47,120-143
NUMA node2 CPU(s):   48-71,144-167
NUMA node3 CPU(s):   72-95,168-191
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke avx512_vnni md_clear flush_l1d arch_capabilities

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling


And guest vulnerability info is different from host when use host-model,(QEMU cli generated is "-cpu Cascadelake-Server,ss=on,vmx=on,hypervisor=on,tsc_adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,hv_time,hv_vapic,hv_spinlocks=0x1000", no mds-no).

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT Host state unknown
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling


BTW, the software version is as below.

qemu-kvm-2.12.0-85.module+el8.1.0+4046+aa244b40
libvirt-client-4.5.0-32.module+el8.1.0+4046+aa244b40.x86_64
kernel-4.18.0-137.el8.x86_64 (both guest and host)

Comment 7 Yumei Huang 2019-08-31 13:40:07 UTC
(In reply to Eduardo Habkost from comment #3)
> I can't reproduce it.  On a host I'm using, mds-no is reported as true.
> 
> # rpm -q qemu-kvm
> qemu-kvm-2.12.0-85.module+el8.1.0+4010+d6842f29.x86_64
> # ps ax | grep qemu
> 31299 pts/2    Sl+    0:00 /usr/libexec/qemu-kvm -machine accel=kvm -qmp
> unix:/tmp/qmp,server
> 31303 pts/1    R+     0:00 grep --color=auto qemu
> # echo 'query-cpu-model-expansion type=full model={"name":"host"}' | python2
> ./scripts/qmp/qmp-shell -p /tmp/qmp | egrep
> 'rdctl-no|ibrs-all|rsba|skip-l1dfl-vmentry|ssb-no|mds-no'
>                 "mds-no": true, 
>                 "rdctl-no": true, 
>                 "ssb-no": false, 
>                 "ibrs-all": true, 
>                 "skip-l1dfl-vmentry": true, 
>                 "rsba": false, 
> #

The difference is you were using model={"name":"host"} while I was using model={"name":"Cascadelake-Server"}.

Comment 8 Eduardo Habkost 2019-09-02 16:15:19 UTC
(In reply to Yumei Huang from comment #7)
> (In reply to Eduardo Habkost from comment #3)
> > I can't reproduce it.  On a host I'm using, mds-no is reported as true.
> > 
> > # rpm -q qemu-kvm
> > qemu-kvm-2.12.0-85.module+el8.1.0+4010+d6842f29.x86_64
> > # ps ax | grep qemu
> > 31299 pts/2    Sl+    0:00 /usr/libexec/qemu-kvm -machine accel=kvm -qmp
> > unix:/tmp/qmp,server
> > 31303 pts/1    R+     0:00 grep --color=auto qemu
> > # echo 'query-cpu-model-expansion type=full model={"name":"host"}' | python2
> > ./scripts/qmp/qmp-shell -p /tmp/qmp | egrep
> > 'rdctl-no|ibrs-all|rsba|skip-l1dfl-vmentry|ssb-no|mds-no'
> >                 "mds-no": true, 
> >                 "rdctl-no": true, 
> >                 "ssb-no": false, 
> >                 "ibrs-all": true, 
> >                 "skip-l1dfl-vmentry": true, 
> >                 "rsba": false, 
> > #
> 
> The difference is you were using model={"name":"host"} while I was using
> model={"name":"Cascadelake-Server"}.

You're right.  I didn't notice that the steps in comment #0 mentioned Cascadelake-Server.
Note that using "Cascadelake-Server" isn't supposed to return mds-no as set, though.

`query-cpu-model-expansion` with model name `Cascadelake-Server` will return
info on the (static) Cascadelake CPU model itself, not the host CPU, and won't
return arch-capabilities or mds-no as enabled.

`query-cpu-model-expansion` with model name `host` will return info on the host
CPU.  This is the mechanism used by libvirt to query for host capabilities.
It should return `arch-capabilities` and `mds-no` as true, if the host have those bits set.

If `virsh domcapabilities` and `mode=host-model` are not working, this is for a
different reason.  Probably because of the `unavailable-features` property, see
bug 1747185.

Should we close this BZ as NOTABUG?

Comment 9 Yumei Huang 2019-09-03 02:59:23 UTC
Thanks Eduardo. I was intended to report the missing bit(mds-no) in virsh domcapabilites, but seems I got wrong root cause in qemu. Since we already have bug 1747185, I'm closing this one, thanks.


Note You need to log in before you can comment on or make changes to this bug.