- Devel - libvirt List Archives

[jenkins-ci PATCH] jenkins: Fix machine order for libvirt-sandbox
by Andrea Bolognani 29 Apr '20

29 Apr '20

Fixes: f7ffff9cd9cc250ac32d7e343c15b4697e931a68 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. jenkins/projects/libvirt-sandbox.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jenkins/projects/libvirt-sandbox.yaml b/jenkins/projects/libvirt-sandbox.yaml index 6a8acec..10c2441 100644 --- a/jenkins/projects/libvirt-sandbox.yaml +++ b/jenkins/projects/libvirt-sandbox.yaml @@ -25,5 +25,5 @@ parent_jobs: 'libvirt-sandbox-check' machines: - libvirt-fedora-30 - - libvirt-fedora-rawhide - libvirt-fedora-31 + - libvirt-fedora-rawhide -- 2.25.4

1 0

[PATCH] docs: Describe protected virtualization guest setup
by Boris Fiuczynski 29 Apr '20

29 Apr '20

From: Viktor Mihajlovski <mihajlov(a)linux.ibm.com> Protected virtualization/IBM Secure Execution for Linux protects guest memory and state from the host. Add some basic information about technology and a brief guide on setting up secure guests with libvirt. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Reviewed-by: Paulo de Rezende Pinatti <ppinatti(a)linux.ibm.com> --- docs/kbase.html.in | 3 + docs/kbase/protected_virtualization.rst | 188 ++++++++++++++++++++++++ 2 files changed, 191 insertions(+) create mode 100644 docs/kbase/protected_virtualization.rst diff --git a/docs/kbase.html.in b/docs/kbase.html.in index c586e0f676..05a3239224 100644 --- a/docs/kbase.html.in +++ b/docs/kbase.html.in @@ -14,6 +14,9 @@ <dt><a href="kbase/secureusage.html">Secure usage</a></dt> <dd>Secure usage of the libvirt APIs</dd> + <dt><a href="kbase/protected_virtualization.html">Protected virtualization</a></dt> + <dd>Running secure guests with IBM Secure Execution</dd> + <dt><a href="kbase/launch_security_sev.html">Launch security</a></dt> <dd>Securely launching VMs with AMD SEV</dd> diff --git a/docs/kbase/protected_virtualization.rst b/docs/kbase/protected_virtualization.rst new file mode 100644 index 0000000000..48f2add14e --- /dev/null +++ b/docs/kbase/protected_virtualization.rst @@ -0,0 +1,188 @@ +======================== +Protected Virtualization +======================== + +.. contents:: + +Overview +======== + +Protected virtualization, also known as IBM Secure Execution is a +hardware-based privacy protection technology for s390x (IBM Z). +It allows to execute virtual machines such that the host system +has no access to a VM's state and memory contents. + +Unlike other similar technologies, the memory of a running guest +is not encrypted but protected by hardware access controls, which +may only be manipulated by trusted system firmware, called +ultravisor. + +For the cases where the host needs access to guest memory (e.g. for +paging), it can request pages to be exported to it. The exported page +will be encrypted with a unique key for the running guest by the +ultravisor. The ultravisor also computes an integrity value for +the page, and stores it in a special table, together with the page +index and a counter. This way it can verify the integrity of +the page content upon re-import into the guest. + +In other cases it may be necessary for a guest to grant the host access +to dedicated memory regions (e.g. for I/O). The guest can request +that the ultravisor removes the memory protection from individual +pages, so that they can be shared with the host. Likewise, the +guest can undo the sharing. + +A secure guest will initially start in a regular non-protected VM. +The start-up is controlled by a small bootstrap program loaded +into memory together with encrypted operating system components and +a control structure (the PV header). +The operating system components (e.g. Linux kernel, initial RAM +file system, kernel parameters) are encrypted and integrity +protected. The component encryption keys and integrity values are +stored in the PV header. +The PV header is wrapped with a public key belonging to a specific +system (in fact it can be wrapped with multiple such keys). The +matching private key is only accessible by trusted hardware and +firmware in that specific system. +Consequently, such a secure guest boot image can only be run on the +systems it has been prepared for. Its contents can't be decrypted +without access to the private key and it can't be modified as +it is integrity protected. + +Host Requirements +================= + +IBM Secure Execution for Linux has some hardware and firmware +requirements. The system hardware must be an IBM z15 (or newer), +or an IBM LinuxONE III (or newer). + +It is also necessary that the IBM Secure Execution feature is +enabled for that system. Check for facility '158', e.g. + +:: + + $ grep facilities /proc/cpuinfo | grep 158 + +The kernel must include the protected virtualization support +which can be verified by checking for the presence of directory +``/sys/firmware/uv``. It will only be present when both the +hardware and the kernel support are available. + +Finally, the host operating system must donate some memory to +the ultravisor needed to store memory security information. +This is achieved by specifying the following kernel command +line parameter to the host boot configuration + +:: + + prot_virt=1 + + +Guest Requirements +================== + +Guest Boot +---------- + +To start a guest in protected virtualization secure mode, the +boot image must have been prepared first with the program +``genprotimg`` using the correct public key for this host. +``genprotimg`` is part of the package ``s390-tools``, or +``s390-utils``, depending on the Linux distribution being used. +It can also be found at +`<https://github.com/ibm-s390-tools/s390-tools/tree/master/genprotimg>`_ + +The guests have to be configured to use the host CPU model, which +must contain the ``unpack`` facility indicating ultravisor guest support. + +With the following command it's possible to check whether the host +CPU model satisfies the requirement + +:: + + $ virsh domcapabilities | grep unpack + +which should return + +:: + + <feature policy='require' name='unpack'/> + +If the check fails despite the host system actually supporting +protected virtualization guests, this can be caused by a stale +libvirt capabilities cache. To recover, run the following +commands + +:: + + $ systemctl stop libvirtd + $ rm /var/cache/libvirt/qemu/capabilities/*.xml + $ systemctl start libvirtd + + +Guest I/O +--------- + +Protected virtualization guests support I/O using virtio devices. +As the virtio datastructures of secure guests are not accessible +by the host, it is necessary to use shared memory ('bounce buffers'). + +To enable virtio devices to use shared buffers, it is necessary +to configure them with platform_iommu enabled. This can done by adding +``iommu='on'`` to the driver element of a virtio device definition in the +guest's XML, e.g. + +:: + + <interface type='network'> + <source network='default'/> + <model type='virtio'/> + <driver name='vhost' iommu='on'/> + </interface> + +It is mandatory to define all virtio bus devices in this way to +prevent the host from attempting to access protected memory. +Ballooning will not work and is fenced by QEMU. It should be +disabled by specifying + +:: + + <memballoon model='none'/> + +Finally, the guest Linux must be instructed to allocate I/O +buffers using memory shared between host and guest using SWIOTLB. +This is done by adding ``swiotlb=nnn`` to the guest's kernel command +line string, where ``nnn`` stands for the number of statically +allocated 2K entries. A commonly used value for swiotlb is 262144. + +Example guest definition +======================== + +Minimal domain XML for a protected virtualization guest, essentially +it's mostly about the ``iommu`` property + +:: + + <domain type='kvm'> + <name>protected</name> + <memory unit='KiB'>2048000</memory> + <currentMemory unit='KiB'>2048000</currentMemory> + <vcpu>1</vcpu> + <os> + <type arch='s390x'>hvm</type> + </os> + <cpu mode='host-model'/> + <devices> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none' io='native' iommu='on'> + <source file='/var/lib/libvirt/images/protected.qcow2'/> + <target dev='vda' bus='virtio'/> + </disk> + <interface type='network'> + <driver iommu='on'/> + <source network='default'/> + <model type='virtio'/> + </interface> + <console type='pty'/> + <memballoon model='none'/> + </devices> + </domain> -- 2.25.1

5 13

[PATCH 0/3] doc: minor improvements
by Sebastian Mitterle 29 Apr '20

29 Apr '20

Minor man/doc improvements related to blockpull. Sebastian Mitterle (3): Improve blockpull man entry Improve Disk image chains documentation Add version info on domaincaps doc docs/formatdomaincaps.html.in | 3 ++- docs/kbase/backing_chains.rst | 36 +++++++++++++++++------------------ docs/manpages/virsh.rst | 19 ++++++++++++------ 3 files changed, 33 insertions(+), 25 deletions(-) -- 2.25.2

3 14

[jenkins-ci PATCH] lcitool: Move gtk-vnc MinGW builds to Fedora Rawhide
by Andrea Bolognani 29 Apr '20

29 Apr '20

When moving MinGW builds off Fedora 30, gtk-vnc was mistakenly left behind. Fixes: 6ede7a19e7aa1670bbe13b10d8014977d3bb2203 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as a CI fix. guests/host_vars/libvirt-fedora-30/main.yml | 2 -- guests/host_vars/libvirt-fedora-rawhide/main.yml | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/guests/host_vars/libvirt-fedora-30/main.yml b/guests/host_vars/libvirt-fedora-30/main.yml index 227db89..a8f6fb9 100644 --- a/guests/host_vars/libvirt-fedora-30/main.yml +++ b/guests/host_vars/libvirt-fedora-30/main.yml @@ -1,8 +1,6 @@ --- projects: - gtk-vnc - - gtk-vnc+mingw32 - - gtk-vnc+mingw64 - libosinfo - libvirt - libvirt-cim diff --git a/guests/host_vars/libvirt-fedora-rawhide/main.yml b/guests/host_vars/libvirt-fedora-rawhide/main.yml index 2367fe1..bd42a87 100644 --- a/guests/host_vars/libvirt-fedora-rawhide/main.yml +++ b/guests/host_vars/libvirt-fedora-rawhide/main.yml @@ -1,6 +1,8 @@ --- projects: - gtk-vnc + - gtk-vnc+mingw32 + - gtk-vnc+mingw64 - libosinfo - libosinfo+mingw32 - libosinfo+mingw64 -- 2.25.4

1 0

[libvirt-perl PATCH v2 0/3] gitlab: introduce CI coverage
by Daniel P. Berrangé 29 Apr '20

29 Apr '20

This series introduces CI jobs for the Perl binding, enabling the switch over to use of Merge Requests with pre-merge build validation. v1: https://www.redhat.com/archives/libvir-list/2020-April/msg01157.html This is a different approach from v1, because we don't inherit from the main libvirt container images. Instead we use the libvirt-minimal project as a dependancy. The cost is that the container build stage is more expensive, but the main project build stage is cheaper. This is a net win because the container build stage is cached so is only a penalty the first time, or when the distro parent image has changes to pull in. It also makes the CI process of the binding more self-contained avoiding by avoiding a dep on the container image for libvirt. Daniel P. Berrangé (3): Build: bump min perl to 5.16.0 gitlab: add CI jobs for validating build across platforms gitlab: add a simple job that publishes the API docs as HTML .gitlab-ci.yml | 158 ++++++++++++++++++++++++++++++++++ Build.PL | 2 +- ci/libvirt-centos-7.dkr | 97 +++++++++++++++++++++ ci/libvirt-centos-8.dkr | 68 +++++++++++++++ ci/libvirt-debian-10.dkr | 68 +++++++++++++++ ci/libvirt-debian-9.dkr | 71 +++++++++++++++ ci/libvirt-debian-sid.dkr | 68 +++++++++++++++ ci/libvirt-fedora-30.dkr | 66 ++++++++++++++ ci/libvirt-fedora-31.dkr | 66 ++++++++++++++ ci/libvirt-fedora-rawhide.dkr | 67 ++++++++++++++ ci/libvirt-opensuse-151.dkr | 66 ++++++++++++++ ci/libvirt-ubuntu-1604.dkr | 71 +++++++++++++++ ci/libvirt-ubuntu-1804.dkr | 71 +++++++++++++++ ci/refresh | 16 ++++ 14 files changed, 954 insertions(+), 1 deletion(-) create mode 100644 ci/libvirt-centos-7.dkr create mode 100644 ci/libvirt-centos-8.dkr create mode 100644 ci/libvirt-debian-10.dkr create mode 100644 ci/libvirt-debian-9.dkr create mode 100644 ci/libvirt-debian-sid.dkr create mode 100644 ci/libvirt-fedora-30.dkr create mode 100644 ci/libvirt-fedora-31.dkr create mode 100644 ci/libvirt-fedora-rawhide.dkr create mode 100644 ci/libvirt-opensuse-151.dkr create mode 100644 ci/libvirt-ubuntu-1604.dkr create mode 100644 ci/libvirt-ubuntu-1804.dkr create mode 100755 ci/refresh -- 2.25.4

1 3

[libvirt-ci PATCH 0/2] Move MinGW builds back to Fedora Rawhide
by Andrea Bolognani 29 Apr '20

29 Apr '20

Andrea Bolognani (2): lcitool: Prepare Fedora Rawhide for MinGW builds Move MinGW builds back to Fedora Rawhide guests/host_vars/libvirt-fedora-30/main.yml | 10 ---------- guests/host_vars/libvirt-fedora-rawhide/main.yml | 10 ++++++++++ guests/playbooks/build/jobs/defaults.yml | 2 +- jenkins/jobs/defaults.yaml | 2 +- 4 files changed, 12 insertions(+), 12 deletions(-) -- 2.25.3

2 4

[libvirt-ci PATCH] containers: New top-level directory
by Andrea Bolognani 29 Apr '20

29 Apr '20

Let's keep the repository structure tidy. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- .gitlab-ci.yml | 2 +- {check-dco => containers/check-dco}/Dockerfile | 0 {check-dco => containers/check-dco}/check-dco.py | 0 3 files changed, 1 insertion(+), 1 deletion(-) rename {check-dco => containers/check-dco}/Dockerfile (100%) rename {check-dco => containers/check-dco}/check-dco.py (100%) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 7735bb3..6de69d6 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -12,7 +12,7 @@ stages: - docker info - docker login registry.gitlab.com -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} script: - - docker build --tag ${CI_REGISTRY_IMAGE}/${NAME}:${CI_COMMIT_REF_SLUG} ${NAME} + - docker build --tag ${CI_REGISTRY_IMAGE}/${NAME}:${CI_COMMIT_REF_SLUG} containers/${NAME} - docker push ${CI_REGISTRY_IMAGE}/${NAME}:${CI_COMMIT_REF_SLUG} after_script: - docker logout diff --git a/check-dco/Dockerfile b/containers/check-dco/Dockerfile similarity index 100% rename from check-dco/Dockerfile rename to containers/check-dco/Dockerfile diff --git a/check-dco/check-dco.py b/containers/check-dco/check-dco.py similarity index 100% rename from check-dco/check-dco.py rename to containers/check-dco/check-dco.py -- 2.25.4

1 0

[libvirt-ci PATCH 0/4] lcitool: Use more dictionaries in the inventory
by Andrea Bolognani 29 Apr '20

29 Apr '20

It's the most sensible way to represent related data in YAML. Andrea Bolognani (4): lcitool: Tweak formatting lcitool: Store OS information a dictionary lcitool: Store packaging information as a dictionary lcitool: Store paths information as a dictionary guests/host_vars/libvirt-centos-7/main.yml | 30 ++-- guests/host_vars/libvirt-centos-8/main.yml | 30 ++-- guests/host_vars/libvirt-debian-10/main.yml | 30 ++-- guests/host_vars/libvirt-debian-9/main.yml | 30 ++-- guests/host_vars/libvirt-debian-sid/main.yml | 30 ++-- guests/host_vars/libvirt-fedora-30/main.yml | 30 ++-- guests/host_vars/libvirt-fedora-31/main.yml | 30 ++-- .../host_vars/libvirt-fedora-rawhide/main.yml | 30 ++-- guests/host_vars/libvirt-freebsd-11/main.yml | 30 ++-- guests/host_vars/libvirt-freebsd-12/main.yml | 30 ++-- .../libvirt-freebsd-current/main.yml | 30 ++-- .../host_vars/libvirt-opensuse-151/main.yml | 30 ++-- guests/host_vars/libvirt-ubuntu-1604/main.yml | 30 ++-- guests/host_vars/libvirt-ubuntu-1804/main.yml | 30 ++-- guests/lcitool | 154 ++++++++---------- guests/playbooks/update/tasks/base.yml | 72 ++++---- guests/playbooks/update/tasks/bootloader.yml | 2 +- guests/playbooks/update/tasks/bootstrap.yml | 6 +- guests/playbooks/update/tasks/gitlab.yml | 2 +- guests/playbooks/update/tasks/global.yml | 4 +- guests/playbooks/update/tasks/jenkins.yml | 2 +- guests/playbooks/update/tasks/kludges.yml | 8 +- guests/playbooks/update/tasks/packages.yml | 24 +-- guests/playbooks/update/tasks/services.yml | 2 +- guests/playbooks/update/tasks/users.yml | 4 +- guests/playbooks/update/templates/bashrc.j2 | 12 +- .../update/templates/jenkins.service.j2 | 2 +- 27 files changed, 380 insertions(+), 334 deletions(-) -- 2.25.4

2 8

[PATCH V4 5/5] cpu_map: Introduce ARM cpu models
by Zhenyu Zheng 29 Apr '20

29 Apr '20

Introduce vendors and some commonly used models for ARM arch, these will be used for virConnectionGetCapabilities for ARM CPUs. Signed-off-by: Zhenyu Zheng <zhengzhenyulixi(a)gmail.com> --- src/cpu_map/Makefile.inc.am | 7 +++++++ src/cpu_map/arm_Falkor.xml | 16 ++++++++++++++++ src/cpu_map/arm_Kunpeng-920.xml | 24 ++++++++++++++++++++++++ src/cpu_map/arm_ThunderX299xx.xml | 16 ++++++++++++++++ src/cpu_map/arm_cortex-a53.xml | 16 ++++++++++++++++ src/cpu_map/arm_cortex-a57.xml | 15 +++++++++++++++ src/cpu_map/arm_cortex-a72.xml | 15 +++++++++++++++ src/cpu_map/arm_vendors.xml | 14 ++++++++++++++ src/cpu_map/index.xml | 15 +++++++++++++++ 9 files changed, 138 insertions(+) create mode 100644 src/cpu_map/arm_Falkor.xml create mode 100644 src/cpu_map/arm_Kunpeng-920.xml create mode 100644 src/cpu_map/arm_ThunderX299xx.xml create mode 100644 src/cpu_map/arm_cortex-a53.xml create mode 100644 src/cpu_map/arm_cortex-a57.xml create mode 100644 src/cpu_map/arm_cortex-a72.xml create mode 100644 src/cpu_map/arm_vendors.xml diff --git a/src/cpu_map/Makefile.inc.am b/src/cpu_map/Makefile.inc.am index be64c9a0d4..5d9190e27d 100644 --- a/src/cpu_map/Makefile.inc.am +++ b/src/cpu_map/Makefile.inc.am @@ -2,7 +2,14 @@ cpumapdir = $(pkgdatadir)/cpu_map cpumap_DATA = \ + cpu_map/arm_cortex-a53.xml \ + cpu_map/arm_cortex-a57.xml \ + cpu_map/arm_cortex-a72.xml \ cpu_map/arm_features.xml \ + cpu_map/arm_Kunpeng-920.xml \ + cpu_map/arm_ThunderX299xx.xml \ + cpu_map/arm_Falkor.xml \ + cpu_map/arm_vendors.xml \ cpu_map/index.xml \ cpu_map/ppc64_vendors.xml \ cpu_map/ppc64_POWER7.xml \ diff --git a/src/cpu_map/arm_Falkor.xml b/src/cpu_map/arm_Falkor.xml new file mode 100644 index 0000000000..902ed2b6ba --- /dev/null +++ b/src/cpu_map/arm_Falkor.xml @@ -0,0 +1,16 @@ +<cpus> + <model name='Falkor'> + <vendor name='Qualcomm'/> + <pvr value='0xc00'/> + <feature name="fp"/> + <feature name="asimd"/> + <feature name="evtstrm"/> + <feature name="aes"/> + <feature name="pmull"/> + <feature name="sha1"/> + <feature name="sha2"/> + <feature name="crc32"/> + <feature name="cpuid"/> + <feature name="asimdrdm"/> + </model> +</cpus> diff --git a/src/cpu_map/arm_Kunpeng-920.xml b/src/cpu_map/arm_Kunpeng-920.xml new file mode 100644 index 0000000000..668b8b50dc --- /dev/null +++ b/src/cpu_map/arm_Kunpeng-920.xml @@ -0,0 +1,24 @@ +<cpus> + <model name='Kunpeng-920'> + <vendor name='HiSilicon'/> + <pvr value='0xd01'/> + <feature name="fp"/> + <feature name="asimd"/> + <feature name="evtstrm"/> + <feature name="aes"/> + <feature name="pmull"/> + <feature name="sha1"/> + <feature name="sha2"/> + <feature name="crc32"/> + <feature name="atomics"/> + <feature name="fphp"/> + <feature name="asimdhp"/> + <feature name="cpuid"/> + <feature name="asimdrdm"/> + <feature name="jscvt"/> + <feature name="fcma"/> + <feature name="dcpop"/> + <feature name="asimddp"/> + <feature name="asimdfhm"/> + </model> +</cpus> diff --git a/src/cpu_map/arm_ThunderX299xx.xml b/src/cpu_map/arm_ThunderX299xx.xml new file mode 100644 index 0000000000..9ab3d939e9 --- /dev/null +++ b/src/cpu_map/arm_ThunderX299xx.xml @@ -0,0 +1,16 @@ +<cpus> + <model name='ThunderX2 99xx'> + <vendor name='Cavium'/> + <pvr value='0x0af'/> + <feature name="fp"/> + <feature name="asimd"/> + <feature name="evtstrm"/> + <feature name="aes"/> + <feature name="pmull"/> + <feature name="sha1"/> + <feature name="sha2"/> + <feature name="crc32"/> + <feature name="cpuid"/> + <feature name="asimdrdm"/> + </model> +</cpus> diff --git a/src/cpu_map/arm_cortex-a53.xml b/src/cpu_map/arm_cortex-a53.xml new file mode 100644 index 0000000000..963d6d36e3 --- /dev/null +++ b/src/cpu_map/arm_cortex-a53.xml @@ -0,0 +1,16 @@ +<cpus> + <model name='cortex-a53'> + <vendor name='ARM'/> + <pvr value='0xd03'/> + <feature name="fp"/> + <feature name="asimd"/> + <feature name="evtstrm"/> + <feature name="aes"/> + <feature name="pmull"/> + <feature name="sha1"/> + <feature name="sha2"/> + <feature name="crc32"/> + <feature name="cpuid"/> + <feature name="asimdrdm"/> + </model> +</cpus> diff --git a/src/cpu_map/arm_cortex-a57.xml b/src/cpu_map/arm_cortex-a57.xml new file mode 100644 index 0000000000..92a044ea92 --- /dev/null +++ b/src/cpu_map/arm_cortex-a57.xml @@ -0,0 +1,15 @@ +<cpus> + <model name='cortex-a57'> + <vendor name='ARM'/> + <pvr value='0xd07'/> + <feature name="fp"/> + <feature name="asimd"/> + <feature name="evtstrm"/> + <feature name="aes"/> + <feature name="pmull"/> + <feature name="sha1"/> + <feature name="sha2"/> + <feature name="crc32"/> + <feature name="cpuid"/> + </model> +</cpus> diff --git a/src/cpu_map/arm_cortex-a72.xml b/src/cpu_map/arm_cortex-a72.xml new file mode 100644 index 0000000000..9664eacd7b --- /dev/null +++ b/src/cpu_map/arm_cortex-a72.xml @@ -0,0 +1,15 @@ +<cpus> + <model name='cortex-a72'> + <vendor name='ARM'/> + <pvr value='0xd08'/> + <feature name="fp"/> + <feature name="asimd"/> + <feature name="evtstrm"/> + <feature name="aes"/> + <feature name="pmull"/> + <feature name="sha1"/> + <feature name="sha2"/> + <feature name="crc32"/> + <feature name="cpuid"/> + </model> +</cpus> diff --git a/src/cpu_map/arm_vendors.xml b/src/cpu_map/arm_vendors.xml new file mode 100644 index 0000000000..703c2112b1 --- /dev/null +++ b/src/cpu_map/arm_vendors.xml @@ -0,0 +1,14 @@ +<cpus> + <vendor name="ARM" value="0x41"/> + <vendor name="Broadcom" value="0x42"/> + <vendor name="Cavium" value="0x43"/> + <vendor name="DigitalEquipment" value="0x44"/> + <vendor name="HiSilicon" value="0x48"/> + <vendor name="Infineon" value="0x49"/> + <vendor name="Freescale" value="0x4D"/> + <vendor name="NVIDIA" value="0x4E"/> + <vendor name="APM" value="0x50"/> + <vendor name="Qualcomm" value="0x51"/> + <vendor name="Marvell" value="0x56"/> + <vendor name="Intel" value="0x69"/> +</cpus> diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index 50b030de29..20646a031c 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -85,6 +85,21 @@ </arch> <arch name='arm'> + <include filename="arm_vendors.xml"/> <include filename='arm_features.xml'/> + +  + <include filename="arm_cortex-a53.xml"/> + <include filename="arm_cortex-a57.xml"/> + <include filename="arm_cortex-a72.xml"/> + +  + <include filename='arm_Falkor.xml'/> + +  + <include filename='arm_ThunderX299xx.xml'/> + +  + <include filename="arm_Kunpeng-920.xml"/> </arch> </cpus> -- 2.26.2

1 1

[PATCH V4 4/5] cpu: Introduce getHost support for ARM CPU driver
by Zhenyu Zheng 29 Apr '20

29 Apr '20

Introduce getHost support for ARM CPU driver, read CPU vendor_id, part_id and flags from registers directly. These codes will only be compiled on aarch64 hardwares. Signed-off-by: Zhenyu Zheng <zhengzhenyulixi(a)gmail.com> --- src/cpu/cpu_arm.c | 201 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 201 insertions(+) diff --git a/src/cpu/cpu_arm.c b/src/cpu/cpu_arm.c index 24404eac2c..887932cc5a 100644 --- a/src/cpu/cpu_arm.c +++ b/src/cpu/cpu_arm.c @@ -21,6 +21,10 @@ */ #include <config.h> +#if defined(__aarch64__) +# include <asm/hwcap.h> +# include <sys/auxv.h> +#endif #include "viralloc.h" #include "cpu.h" @@ -31,6 +35,12 @@ #include "virxml.h" #define VIR_FROM_THIS VIR_FROM_CPU +#if defined(__aarch64__) +/* Shift bit mask for parsing cpu flags */ +# define BIT_SHIFTS(n) (1UL << (n)) +/* The current max number of cpu flags on ARM is 32 */ +# define MAX_CPU_FLAGS 32 +#endif VIR_LOG_INIT("cpu.cpu_arm"); @@ -495,12 +505,203 @@ virCPUarmValidateFeatures(virCPUDefPtr cpu) return 0; } +#if defined(__aarch64__) +/** + * virCPUarmCpuDataFromRegs: + * + * @data: 64-bit arm CPU specific data + * + * Fetches CPU vendor_id and part_id from MIDR_EL1 register, parse CPU + * flags from AT_HWCAP. There are currently 32 valid flags on ARM arch + * represented by each bit. + */ +static int +virCPUarmCpuDataFromRegs(virCPUarmData *data) +{ + /* Generate human readable flag list according to the order of */ + /* AT_HWCAP bit map */ + const char *flag_list[MAX_CPU_FLAGS] = { + "fp", "asimd", "evtstrm", "aes", "pmull", "sha1", "sha2", + "crc32", "atomics", "fphp", "asimdhp", "cpuid", "asimdrdm", + "jscvt", "fcma", "lrcpc", "dcpop", "sha3", "sm3", "sm4", + "asimddp", "sha512", "sve", "asimdfhm", "dit", "uscat", + "ilrcpc", "flagm", "ssbs", "sb", "paca", "pacg"}; + unsigned long cpuid, hwcaps; + char **features = NULL; + g_autofree char *cpu_feature_str = NULL; + int cpu_feature_index = 0; + size_t i; + + if (!(getauxval(AT_HWCAP) & HWCAP_CPUID)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("CPUID registers unavailable")); + return -1; + } + + /* read the cpuid data from MIDR_EL1 register */ + asm("mrs %0, MIDR_EL1" : "=r" (cpuid)); + VIR_DEBUG("CPUID read from register: 0x%016lx", cpuid); + + /* parse the coresponding part_id bits */ + data->pvr = cpuid>>4&0xFFF; + /* parse the coresponding vendor_id bits */ + data->vendor_id = cpuid>>24&0xFF; + + hwcaps = getauxval(AT_HWCAP); + VIR_DEBUG("CPU flags read from register: 0x%016lx", hwcaps); + + if (VIR_ALLOC_N(features, MAX_CPU_FLAGS) < 0) + return -1; + + /* shift bit map mask to parse for CPU flags */ + for (i = 0; i< MAX_CPU_FLAGS; i++) { + if (hwcaps & BIT_SHIFTS(i)) { + features[cpu_feature_index] = g_strdup(flag_list[i]); + cpu_feature_index++; + } + } + + if (cpu_feature_index > 1) { + cpu_feature_str = virStringListJoin((const char **)features, " "); + if (!cpu_feature_str) + goto error; + } + data->features = g_strdup(cpu_feature_str); + + return 0; + + error: + virStringListFree(features); + return -1; +} + +static int +virCPUarmDataParseFeatures(virCPUDefPtr cpu, + const virCPUarmData *cpuData) +{ + int ret = -1; + size_t i; + char **features; + + if (!cpu || !cpuData) + return ret; + + if (!(features = virStringSplitCount(cpuData->features, " ", + 0, &cpu->nfeatures))) + return ret; + if (cpu->nfeatures) { + if (VIR_ALLOC_N(cpu->features, cpu->nfeatures) < 0) + goto error; + + for (i = 0; i < cpu->nfeatures; i++) { + cpu->features[i].policy = VIR_CPU_FEATURE_REQUIRE; + cpu->features[i].name = g_strdup(features[i]); + } + } + + ret = 0; + + cleanup: + virStringListFree(features); + return ret; + + error: + for (i = 0; i < cpu->nfeatures; i++) + VIR_FREE(cpu->features[i].name); + VIR_FREE(cpu->features); + cpu->nfeatures = 0; + goto cleanup; +} + +static int +virCPUarmDecode(virCPUDefPtr cpu, + const virCPUarmData *cpuData, + virDomainCapsCPUModelsPtr models) +{ + virCPUarmMapPtr map; + virCPUarmModelPtr model; + virCPUarmVendorPtr vendor = NULL; + + if (!cpuData || !(map = virCPUarmGetMap())) + return -1; + + if (!(model = virCPUarmModelFindByPVR(map, cpuData->pvr))) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("Cannot find CPU model with PVR 0x%03lx"), + cpuData->pvr); + return -1; + } + + if (!virCPUModelIsAllowed(model->name, models)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("CPU model %s is not supported by hypervisor"), + model->name); + return -1; + } + + cpu->model = g_strdup(model->name); + + if (cpuData->vendor_id && + !(vendor = virCPUarmVendorFindByID(map, cpuData->vendor_id))) { + virReportError(VIR_ERR_OPERATION_FAILED, + _("Cannot find CPU vendor with vendor id 0x%02lx"), + cpuData->vendor_id); + return -1; + } + + if (vendor) + cpu->vendor = g_strdup(vendor->name); + + if (cpuData->features && + virCPUarmDataParseFeatures(cpu, cpuData) < 0) + return -1; + + return 0; +} + +static int +virCPUarmDecodeCPUData(virCPUDefPtr cpu, + const virCPUData *data, + virDomainCapsCPUModelsPtr models) +{ + return virCPUarmDecode(cpu, &data->data.arm, models); +} + +static int +virCPUarmGetHost(virCPUDefPtr cpu, + virDomainCapsCPUModelsPtr models) +{ + virCPUDataPtr cpuData = NULL; + int ret = -1; + + if (virCPUarmDriverInitialize() < 0) + goto cleanup; + + if (!(cpuData = virCPUDataNew(archs[0]))) + goto cleanup; + + if (virCPUarmCpuDataFromRegs(&cpuData->data.arm) < 0) + goto cleanup; + + ret = virCPUarmDecodeCPUData(cpu, cpuData, models); + + cleanup: + virCPUarmDataFree(cpuData); + return ret; +} +#endif + struct cpuArchDriver cpuDriverArm = { .name = "arm", .arch = archs, .narch = G_N_ELEMENTS(archs), .compare = virCPUarmCompare, +#if defined(__aarch64__) + .getHost = virCPUarmGetHost, + .decode = virCPUarmDecodeCPUData, +#else .decode = NULL, +#endif .encode = NULL, .dataFree = virCPUarmDataFree, .baseline = virCPUarmBaseline, -- 2.26.2

1 1