1559835 – [RFC] Fine-grained API to validate if a given CPU model and flags are supported by QEMU / KVM

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1559835 - [RFC] Fine-grained API to validate if a given CPU model and flags are supported by QEMU / KVM

Summary: [RFC] Fine-grained API to validate if a given CPU model and flags are support...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	libvirt
Sub Component:
Version:	7.6
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Jiri Denemark
QA Contact:	jiyan
Docs Contact:
URL:
Whiteboard:
Depends On:	1559832
Blocks:	1511996
TreeView+	depends on / blocked

Reported:	2018-03-23 11:44 UTC by Kashyap Chamarthy
Modified:	2018-10-30 09:55 UTC (History)
CC List:	13 users (show)
Fixed In Version:	libvirt-4.4.0-1.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:	1559832
Environment:
Last Closed:	2018-10-30 09:53:26 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2018:3113	0	None	None	None	2018-10-30 09:55:50 UTC

Description Kashyap Chamarthy 2018-03-23 11:44:26 UTC

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

There is no existing way (near as I know) way to validate if a given libvirt CPU model and a set of extra CPU flags (e.g. IvyBridge with 'pcid' and 'pdpe1gb') are supported by KVM and a given specific QEMU binary.

This is an RFC requesting to add such an API.


Additional info:
----------------

However, what does exist today is a way to check if a given CPU + extra CPU feature flags are supported by the *host* CPU, via the libvirt API virConnectCompareCPU().

Comment 2 Kashyap Chamarthy 2018-03-23 11:46:18 UTC

Jiri Denemark also said this RFC is a prerequisite for the following:

    https://bugzilla.redhat.com/show_bug.cgi?id=1511996
    Implement "virsh cpu-compare" for s390x

Comment 3 Jiri Denemark 2018-05-16 09:50:48 UTC

Patches sent upstream for review: https://www.redhat.com/archives/libvir-list/2018-May/msg01204.html

Comment 4 Jiri Denemark 2018-05-28 14:33:51 UTC

This API is now implemented upstream by a series of patches ending with

commit 75e7ab1ef5f391252685f7a7a0da324f6e2a2ebd
Refs: 4.3.0-356-g75e7ab1ef5
Author:     Jiri Denemark <jdenemar>
AuthorDate: Wed May 16 10:05:57 2018 +0200
Commit:     Jiri Denemark <jdenemar>
CommitDate: Mon May 28 16:00:20 2018 +0200

    news: Mention new CPU related APIs

    Signed-off-by: Jiri Denemark <jdenemar>
    Reviewed-by: Ján Tomko <jtomko>

Comment 6 jiyan 2018-06-27 08:24:52 UTC

Version:
qemu-kvm-rhev-2.12.0-5.el7.x86_64
libvirt-4.4.0-2.el7.x86_64
kernel-3.10.0-915.el7.x86_64

1. Test scenarios for 'virsh cpu-compare' cmd 
In addition to the <cpu> element itself, this command accepts full domain XML, capabilities XML, or domain capabilities XML containing the CPU definition.

**S1**. Test 'virsh cpu-compare' with domain XML
**S1-1**: Domain XML contains <CPU> definition in ‘custom’ mode 
# virsh domstate b1
running

# virsh dumpxml b1 |grep "<cpu" -A9
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='invtsc'/>
 **<feature policy='require' name='hypervisor'/>**
  </cpu>

# virsh dumpxml b1 > b1.xml

# virsh cpu-compare b1.xml 
CPU described in b1.xml is incompatible with host CPU


**S1-2**: Domain XML contains <CPU> definition in ‘host-passthrough’ mode 
# virsh domstate b1
running

# virsh dumpxml b1 |grep "<cpu" 
  <cpu mode='host-passthrough' check='none'/>

# virsh dumpxml b1 > b1.xml

# virsh cpu-compare b1.xml 
Host CPU is a superset of CPU described in b1.xml


**S2**. Test 'virsh cpu-compare' with capabilities XML
**S2-1**. Obtain capabilities XML from ‘virsh capabilities’ in local Intel host
# virsh capabilities > capabilities.xml

# virsh cpu-compare capabilities.xml 
CPU described in capabilities.xml is identical to host CPU


**S2-2**. Obtain capabilities XML from ‘virsh capabilities’ in another AMD physical host
# virsh cpu-compare capabilities.xml 
CPU described in capabilities.xml is incompatible with host CPU


**S2-3**. Obtain capabilities XML from ‘virsh capabilities’ in local Intel host, and delete seveval <feature>
# virsh capabilities > capabilities.xml, delete several lines of <feature>

# virsh cpu-compare capabilities.xml 
Host CPU is a superset of CPU described in capabilities.xml


**S3**. Test 'virsh cpu-compare' with domain capabilities XML
# virsh domcapabilities > domcapabilities

# virsh cpu-compare domcapabilities.xml 
CPU described in domcapabilities.xml is incompatible with host CPU


**S4**. Test 'virsh cpu-compare' with <cpu> element
**S4-1**. Extract <CPU> definition from Domain XML
# cat cpu1.xml 
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='invtsc'/>
 **<feature policy='require' name='hypervisor'/>**
  </cpu>

# virsh cpu-compare cpu1.xml 
CPU described in cpu1.xml is incompatible with host CPU


**S4-2**. Extract <CPU> definition from capabilities XML
# cat cpu2.xml 
    <cpu>
      <arch>x86_64</arch>
      <model>Skylake-Client-IBRS</model>
      <vendor>Intel</vendor>
      <microcode version='198'/>
      <topology sockets='1' cores='4' threads='2'/>
      <feature name='ds'/>
      <feature name='acpi'/>
      <feature name='ss'/>
      <feature name='ht'/>
      <feature name='tm'/>
      <feature name='pbe'/>
      <feature name='dtes64'/>
      <feature name='monitor'/>
      <feature name='ds_cpl'/>
      <feature name='vmx'/>
      <feature name='smx'/>
      <feature name='est'/>
      <feature name='tm2'/>
      <feature name='xtpr'/>
      <feature name='pdcm'/>
      <feature name='osxsave'/>
      <feature name='tsc_adjust'/>
      <feature name='clflushopt'/>
      <feature name='stibp'/>
      <feature name='ssbd'/>
      <feature name='xsaves'/>
      <feature name='pdpe1gb'/>
      <feature name='invtsc'/>
      <pages unit='KiB' size='4'/>
      <pages unit='KiB' size='2048'/>
      <pages unit='KiB' size='1048576'/>
    </cpu>

# virsh cpu-compare cpu2.xml 
CPU described in cpu2.xml is identical to host CPU


**S4-3**. Extract <CPU> definition from domcapabilities XML
# cat cpu3.xml 
  <cpu>
    <mode name='host-passthrough' supported='yes'/>
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>Skylake-Client-IBRS</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pdpe1gb'/>
      <feature policy='require' name='invtsc'/>
    </mode>
    <mode name='custom' supported='yes'>
      <model usable='yes'>qemu64</model>
      …
      <model usable='yes'>486</model>
    </mode>
  </cpu>

# virsh cpu-compare cpu3.xml 
Host CPU is a superset of CPU described in cpu3.xml


**S5**, Test 'virsh cpu-compare' with illegal <cpu> definition
Extract <CPU> definition from Domain XML, and add <host> outside of <cpu>
# cat illegal-cpu.xml 
<host>
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='invtsc'/>
 **<feature policy='require' name='hypervisor'/>**
  </cpu>
</host>

# virsh cpu-compare illegal-cpu.xml 
error: File 'illegal-path.xml' does not contain any <cpu> element or valid domain XML, host capabilities XML, or domain capabilities XML

Comment 7 jiyan 2018-06-27 08:26:12 UTC

2.  Test scenarios for 'virsh hypervisor-cpu-compare' cmd
In addition to the <cpu> element itself, this command accepts full domain XML, capabilities XML, or domain capabilities XML containing the CPU definition.

**S1**. Test 'virsh hypervisor-cpu-compare' with domain XML
**S1-1**: Domain XML contains <CPU> definition in ‘custom’ mode 
# virsh domstate b1
running

Configure inactive XML according to ‘virsh domcapabilities’
# virsh dumpxml b1 |grep "<cpu" -A9	 
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='invtsc'/>
   <feature policy='require' name='hypervisor'/>
  </cpu>

# virsh dumpxml b1 > b1.xml

# virsh hypervisor-cpu-compare b1.xml 
CPU described in b1.xml is identical to the CPU provided by hypervisor on the host


**S1-2**: Domain XML contains <CPU> definition in ‘host-passthrough’ mode 
# virsh domstate b1
running

# virsh dumpxml b1 |grep "<cpu" 
  <cpu mode='host-passthrough' check='none'/>

# virsh dumpxml b1 > b1.xml

# virsh hypervisor-cpu-compare b1.xml 
The CPU provided by hypervisor on the host is a superset of CPU described in b1.xml


**S2**. Test 'virsh hypervisor-cpu-compare' with capabilities XML
# virsh capabilities > capabilities.xml 

# virsh hypervisor-cpu-compare capabilities.xml 
CPU described in capabilities.xml is incompatible with the CPU provided by hypervisor on the host


**S3**. Test 'virsh hypervisor-cpu-compare' with domcapabilities XML
# virsh domcapabilities > domcapabilities.xml 

# virsh hypervisor-cpu-compare domcapabilities.xml 
CPU described in domcapabilities.xml is identical to the CPU provided by hypervisor on the host


**S4**. Test 'virsh hypervisor-cpu-compare' with <CPU> definition
Extract <CPU> definition from domcapabilities XML
# cat cpu.xml 
  <cpu>
    <mode name='host-passthrough' supported='yes'/>
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>Skylake-Client-IBRS</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pdpe1gb'/>
      <feature policy='require' name='invtsc'/>
    </mode>
    <mode name='custom' supported='yes'>
      <model usable='yes'>qemu64</model>
      …
      <model usable='yes'>486</model>
    </mode>
  </cpu>

# virsh hypervisor-cpu-compare cpu.xml 
The CPU provided by hypervisor on the host is a superset of CPU described in cpu.xml


**S5**, Test 'virsh hypervisor-cpu-compare' with illegal <cpu> definition
Extract <CPU> definition from Domain XML, and add <host> outside of <cpu>
# cat illegal-cpu.xml 
<host>
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client-IBRS</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='clflushopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='invtsc'/>
 **<feature policy='require' name='hypervisor'/>**
  </cpu>
</host>

# virsh hypervisor-cpu-compare illegal-cpu.xml 
error: File 'illegal-cpu.xml' does not contain any <cpu> element or valid domain XML, host capabilities XML, or domain capabilities XML


**S6**. Parameters testing
# virsh domcapabilities > intel-domhycap1.xml

**S6-1**. ‘virttype’ parameter
# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --error
CPU described in intel-domhycap1.xml is identical to the CPU provided by hypervisor on the host

# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype @ --error
error: Failed to compare hypervisor CPU with intel-domhycap1.xml
error: invalid argument: unknown virttype: @


**S6-2**. ‘virttype’ / ‘emulator’ parameter
# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --error
CPU described in intel-domhycap1.xml is identical to the CPU provided by hypervisor on the host

# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --emulator /usr/libexec/qemu-kvm123 --error
error: Failed to compare hypervisor CPU with intel-domhycap1.xml
error: Cannot check QEMU binary /usr/libexec/qemu-kvm123: No such file or directory


**S6-3**. ‘virttype’ / ‘emulator’ / ‘arch’ parameter
# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64 --error
CPU described in intel-domhycap1.xml is identical to the CPU provided by hypervisor on the host

# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch ** --error
error: unexpected data 'intel-domhycap2.xml'


**S6-4**. ‘virttype’ / ‘emulator’ / ‘arch’ / ‘machine’ parameter
# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64 --machine rhel6.6.0 --error
CPU described in intel-domhycap1.xml is identical to the CPU provided by hypervisor on the host

# virsh hypervisor-cpu-compare intel-domhycap1.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64 --machine rhel --error
error: Failed to compare hypervisor CPU with intel-domhycap1.xml
error: invalid argument: the machine 'rhel' is not supported by emulator '/usr/libexec/qemu-kvm'

Comment 8 jiyan 2018-06-27 08:27:13 UTC

3. Test scenarios for 'virsh cpu-baseline' cmd
Thus, the <file> can contain either a set of <cpu> elements separated by new lines or even a set of complete <capabilities> elements printed by capabilities command.

**S1**. Compute cpubaseline with capabilities XML
Host1: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz	# virsh capabilities > cap1.xml
Host2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz		# virsh capabilities > cap2.xml
Host3: AMD EPYC 7251 8-Core Processor			# virsh capabilities > cap3.xml

**S1-1**. Compute cpu-baseline between host1 and host2
# cat cap1.xml > cap-1-2.xml
# cat cap2.xml >> cap-1-2.xml

# virsh cpu-baseline cap-1-2.xml 
<cpu mode='custom' match='exact'>
  <model fallback='allow'>SandyBridge-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ds'/>
  <feature policy='require' name='acpi'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='ht'/>
  <feature policy='require' name='tm'/>
  <feature policy='require' name='pbe'/>
  <feature policy='require' name='dtes64'/>
  <feature policy='require' name='monitor'/>
  <feature policy='require' name='ds_cpl'/>
  <feature policy='require' name='vmx'/>
  <feature policy='require' name='smx'/>
  <feature policy='require' name='est'/>
  <feature policy='require' name='tm2'/>
  <feature policy='require' name='xtpr'/>
  <feature policy='require' name='pdcm'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='osxsave'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='stibp'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>


**S1-2**. Compute cpu-baseline between host1 and host3
# cat cap1.xml > cap-1-3.xml
# cat cap3.xml >> cap-1-3.xml

# virsh cpu-baseline cap-1-3.xml 
error: operation failed: CPU vendors do not match


**S2**. Compute cpubaseline with <cpu> definition
Host1: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz	# virsh capabilities > cap1.xml
Host2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz		# virsh capabilities > cap2.xml
Extract <cpu> definition among cap1.xml and cap2.xml then save as cpu.xml
# virsh cpu-baseline cpu.xml 
<cpu mode='custom' match='exact'>
  <model fallback='allow'>SandyBridge-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ds'/>
  <feature policy='require' name='acpi'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='ht'/>
  <feature policy='require' name='tm'/>
  <feature policy='require' name='pbe'/>
  <feature policy='require' name='dtes64'/>
  <feature policy='require' name='monitor'/>
  <feature policy='require' name='ds_cpl'/>
  <feature policy='require' name='vmx'/>
  <feature policy='require' name='smx'/>
  <feature policy='require' name='est'/>
  <feature policy='require' name='tm2'/>
  <feature policy='require' name='xtpr'/>
  <feature policy='require' name='pdcm'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='osxsave'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='stibp'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>


**S3**. Compute cpubaseline with domcapabilities XML (Negative)
Host1: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz	# virsh domcapabilities > cap1.xml
Host2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz		# virsh domcapabilities > cap2.xml

#  cat cap1.xml > cap.xml; cat cap2.xml >> cap.xml

# cat cap.xml |grep arch
  <arch>x86_64</arch>
  <arch>x86_64</arch>

# virsh cpu-baseline cap.xml 
error: XML error: Missing CPU architecture

Comment 9 jiyan 2018-06-27 08:34:50 UTC

4. Test scenarios for 'virsh hypervisor-cpu-baseline' cmd
In addition to the <cpu> elements, this command accepts full capabilities XMLs, or domain capabilities XMLs containing the CPU definitions.

**S1**. Compute cpubaseline with capabilities XML
Host1: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz	# virsh capabilities > cap1.xml
Host2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz		# virsh capabilities > cap2.xml
# cat cap1.xml > cap.xml, cat cap2.xml >> cap.xml

# virsh hypervisor-cpu-baseline cap.xml 
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ds'/>
  <feature policy='require' name='acpi'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='ht'/>
  <feature policy='require' name='tm'/>
  <feature policy='require' name='pbe'/>
  <feature policy='require' name='dtes64'/>
  <feature policy='require' name='monitor'/>
  <feature policy='require' name='ds_cpl'/>
  <feature policy='require' name='vmx'/>
  <feature policy='require' name='smx'/>
  <feature policy='require' name='est'/>
  <feature policy='require' name='tm2'/>
  <feature policy='require' name='xtpr'/>
  <feature policy='require' name='pdcm'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='osxsave'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>


**S2**. Compute cpubaseline with domcapabilities XML
Host1: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz	# virsh domcapabilities > cap1.xml
Host2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz		# virsh domcapabilities > cap2.xml
# cat cap1.xml > cap.xml, cat cap2.xml >> cap.xml

# virsh hypervisor-cpu-baseline cap.xml 
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>


**S3**. Compute cpubaseline with <cpu> definition
Extract <cpu> definition from 2 VMs respectively running on 2 physical hosts
# cat cpu.xml 
<cpu mode='custom' match='exact' check='full'>
  <model fallback='forbid'>Skylake-Client-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='clflushopt'/>
  <feature policy='require' name='pdpe1gb'/>
  <feature policy='require' name='invtsc'/>
  <feature policy='require' name='hypervisor'/>
</cpu>
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
    <feature policy='require' name='hypervisor'/>
</cpu>

# virsh hypervisor-cpu-baseline cpu.xml 
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge-IBRS</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>


**S4**. Parameters testing 
(host1) # virsh domcapabilities > intel-domcap1.xml 
(host2) # virsh domcapabilities > intel-domcap2.xml
# cat intel-domcap1.xml > intel-domcap-1-2.xml
# cat intel-domcap2.xml >> intel-domcap-1-2.xml
*S4-1**. ‘virttype’ parameter
# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm 
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>

# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype 123
error: invalid argument: unknown virttype: 123


**S4-2**. ‘virttype’ / ‘emulator’ parameter
# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm 
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>

# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm123
error: Cannot check QEMU binary /usr/libexec/qemu-kvm123: No such file or directory


**S4-3**. ‘virttype’ / ‘emulator’ / ‘arch’ parameter
# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>

# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch 123#
error: invalid argument: unknown architecture: 123#


**S4-4**. ‘virttype’ / ‘emulator’ / ‘arch’ / ‘machine’ parameter
# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64 --machine pc-q35-rhel7.3.0
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='xsaveopt'/>
  <feature policy='require' name='invtsc'/>
</cpu>

# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64 --machine pc-q35-123
error: invalid argument: the machine 'pc-q35-123' is not supported by emulator '/usr/libexec/qemu-kvm'


**S4-5**. ‘virttype’ / ‘emulator’ / ‘arch’ / ‘machine’ / ‘features’ / ‘mirgatable’ parameter
# cat intel-domcap-1-2.xml |grep invtsc
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='invtsc'/>

# virsh hypervisor-cpu-baseline intel-domcap-1-2.xml --virttype kvm --emulator /usr/libexec/qemu-kvm --arch x86_64 --machine pc-q35-rhel7.3.0 --features --migratable
<cpu mode='custom' match='exact'>
  <model fallback='forbid'>SandyBridge</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='aes'/>
  <feature policy='require' name='apic'/>
  <feature policy='require' name='arat'/>
  <feature policy='require' name='avx'/>
  <feature policy='require' name='clflush'/>
  <feature policy='require' name='cmov'/>
  <feature policy='require' name='cx16'/>
  <feature policy='require' name='cx8'/>
  <feature policy='require' name='de'/>
  <feature policy='require' name='fpu'/>
  <feature policy='require' name='fxsr'/>
  <feature policy='require' name='hypervisor'/>
  <feature policy='require' name='lahf_lm'/>
  <feature policy='require' name='lm'/>
  <feature policy='require' name='mca'/>
  <feature policy='require' name='mce'/>
  <feature policy='require' name='mmx'/>
  <feature policy='require' name='msr'/>
  <feature policy='require' name='mtrr'/>
  <feature policy='require' name='nx'/>
  <feature policy='require' name='pae'/>
  <feature policy='require' name='pat'/>
  <feature policy='require' name='pcid'/>
  <feature policy='require' name='pclmuldq'/>
  <feature policy='require' name='pge'/>
  <feature policy='require' name='pni'/>
  <feature policy='require' name='popcnt'/>
  <feature policy='require' name='pse'/>
  <feature policy='require' name='pse36'/>
  <feature policy='require' name='rdtscp'/>
  <feature policy='require' name='sep'/>
  <feature policy='require' name='ss'/>
  <feature policy='require' name='sse'/>
  <feature policy='require' name='sse2'/>
  <feature policy='require' name='sse4.1'/>
  <feature policy='require' name='sse4.2'/>
  <feature policy='require' name='ssse3'/>
  <feature policy='require' name='syscall'/>
  <feature policy='require' name='tsc'/>
  <feature policy='require' name='tsc-deadline'/>
  <feature policy='require' name='tsc_adjust'/>
  <feature policy='require' name='vme'/>
  <feature policy='require' name='x2apic'/>
  <feature policy='require' name='xsave'/>
  <feature policy='require' name='xsaveopt'/>
</cpu>

Comment 10 jiyan 2018-06-27 08:39:17 UTC

Hi, Jiri.
Coule you please explain whether the following scenarios are as expected?
Thank you.

https://bugzilla.redhat.com/show_bug.cgi?id=1559835#c7
S3 and S4, the <cpu> definition in S4 is extracted from 'virsh domcapabilities' in S3, while the results of 'hypervisor-cpu-compare' are different.

https://bugzilla.redhat.com/show_bug.cgi?id=1559835#c8
The negative test scenario, error info maybe is a little confusing.

Comment 11 Jiri Denemark 2018-06-27 11:55:19 UTC

(In reply to jiyan from comment #10)
> https://bugzilla.redhat.com/show_bug.cgi?id=1559835#c7
> S3 and S4, the <cpu> definition in S4 is extracted from 'virsh
> domcapabilities' in S3, while the results of 'hypervisor-cpu-compare' are
> different.

S4 in comment #7 does not use a valid CPU definition XML. It should have
failed with an error message similar to S5. Although we should probably change
"<cpu> element" to "CPU definition XML".

> https://bugzilla.redhat.com/show_bug.cgi?id=1559835#c8
> The negative test scenario, error info maybe is a little confusing.

cpu-baseline requires host CPU definition which contains <arch> element within
the <cpu> element. The CPU definition extracted from domcapabilities does not
meet this expectation and thus libvirt fails to parse the CPU. The <arch>
elements you found in cap.xml are outside <cpu> and they are ignored.

The compare and baseline virsh commands (both the old and the new hypervisor
versions) allow domain, capabilities, or domcapabilities XMLs to save users
from having to extract the right CPU definitions manually. The libvirt API
only allows CPU definition XMLs. To )ix these issues (and bug 1592737) we need
to make the CPU extracting code in virsh smarter. Please, file a new bug for
this.

Comment 13 errata-xmlrpc 2018-10-30 09:53:26 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3113

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