Re: [PATCH] qemu: fix code format problem
by yubihong
OK, Michal. I will do this job later, thanks for your advice.
> On 4/26/20 1:56 PM, yubihong wrote:
> > There are some code format problems in src/libvirt-domain.c. This
> > patch fixes these problems.
> >
> >>From 55cd85345b2dc50f44c1e382563482d40142382b Mon Sep 17 00:00:00
> > 2001
> > From: yubihong <yubihong(a)huawei.com>
> > Date: Fri, 24 Apr 2020 17:44:43 +0800
> > Subject: [PATCH] qemu: fix code format problem
> >
> > Signed-off-by:Yu Bihong <yubihong(a)huawei.com>
> > ---
> > src/libvirt-domain.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index
> > a12809c..d659f1b
> > 100644
> > --- a/src/libvirt-domain.c
> > +++ b/src/libvirt-domain.c
> > @@ -8194,11 +8194,11 @@ virDomainAttachDevice(virDomainPtr domain,
> > const char *xml)
> > virCheckReadOnlyGoto(conn->flags, error);
> >
> > if (conn->driver->domainAttachDevice) {
> > - int ret;
> > - ret = conn->driver->domainAttachDevice(domain, xml);
> > - if (ret < 0)
> > - goto error;
> > - return ret;
> > + int ret;
> > + ret = conn->driver->domainAttachDevice(domain, xml);
> > + if (ret < 0)
> > + goto error;
> > + return ret;
> > }
> >
> > virReportUnsupportedError();
> > @@ -8299,9 +8299,9 @@ virDomainDetachDevice(virDomainPtr domain,
> const
> > char *xml)
> > if (conn->driver->domainDetachDevice) {
> > int ret;
> > ret = conn->driver->domainDetachDevice(domain, xml);
> > - if (ret < 0)
> > - goto error;
> > - return ret;
> > + if (ret < 0)
> > + goto error;
> > + return ret;
> > }
> >
> > virReportUnsupportedError();
> > --
> > 1.8.3.1
> >
>
> This patch doesn't apply cleanly. Can you please resend using git-send-email
> as our documentation suggest?
>
> https://libvirt.org/submitting-patches.html
>
> The idea looks good, but I guess there are more places in the file that are
> misaligned. Might be worth extending your patch and include them.
>
> Michal
4 years, 7 months
[libvirt-ci PATCH] vars: Add python3-wheel to the base package dependencies
by Erik Skultety
On platforms where we need to install meson from pip, one will very
likely see something similar to this when building a container from the
generated Dockerfile:
Collecting meson==0.49.0
Downloading <url>/meson-0.49.0.tar.gz (1.3MB)
100% |################################| 1.3MB 874kB/s
Building wheels for collected packages: meson
Running setup.py bdist_wheel for meson ... error
error: invalid command 'bdist_wheel'
----------------------------------------
Failed building wheel for meson
Running setup.py clean for meson
Failed to build meson
Pip is missing the 'wheel' package necessary to build a wheel from
sources, if it fails to do that, it falls back to the good old:
$ setup.py install meson
which succeeds and no harm was done. However, seeing an error in the
log always raises eyebrows, so let's fix that very simply by installing
the 'wheel' package which is available on all supported platforms.
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
Alternatively, we could use --no-cache-dir with pip install, but I'm not sure
whether it would be enough with new versions of pip. I still feel like
installing the 'wheel' package explicitly is a more transparent and safe fix
even though we don't benefit from the resulting meson wheel package inside
containers at all.
guests/vars/mappings.yml | 4 ++++
guests/vars/projects/base.yml | 1 +
2 files changed, 5 insertions(+)
diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 753f0fe..4a19fb4 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -909,6 +909,10 @@ mappings:
default: python3-setuptools
FreeBSD: py37-setuptools
+ python3-wheel:
+ default: python3-wheel
+ FreeBSD: py37-wheel
+
qemu-img:
default: qemu-utils
rpm: qemu-img
diff --git a/guests/vars/projects/base.yml b/guests/vars/projects/base.yml
index 29c10b4..81c4462 100644
--- a/guests/vars/projects/base.yml
+++ b/guests/vars/projects/base.yml
@@ -28,6 +28,7 @@ packages:
- python3
- python3-pip
- python3-setuptools
+ - python3-wheel
- rpmbuild
- screen
- strace
--
2.25.3
4 years, 7 months
[libvirt-jenkins-ci PATCH] guests: Run libvirt-dbus test suite on Fedora 31
by Andrea Bolognani
This was left out by mistake.
Fixes: f7ffff9cd9cc250ac32d7e343c15b4697e931a68
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as trivial.
guests/playbooks/build/projects/libvirt-dbus.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/guests/playbooks/build/projects/libvirt-dbus.yml b/guests/playbooks/build/projects/libvirt-dbus.yml
index e29d74b..4cf435d 100644
--- a/guests/playbooks/build/projects/libvirt-dbus.yml
+++ b/guests/playbooks/build/projects/libvirt-dbus.yml
@@ -19,6 +19,7 @@
- libvirt-debian-10
- libvirt-debian-sid
- libvirt-fedora-30
+ - libvirt-fedora-31
- libvirt-fedora-rawhide
- libvirt-opensuse-151
- libvirt-ubuntu-1804
--
2.25.4
4 years, 7 months
[jenkins-ci PATCH] jenkins: Fix machine order for libvirt-sandbox
by Andrea Bolognani
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
4 years, 7 months
[PATCH] docs: Describe protected virtualization guest setup
by Boris Fiuczynski
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
4 years, 7 months
[PATCH 0/3] doc: minor improvements
by Sebastian Mitterle
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
4 years, 7 months
[jenkins-ci PATCH] lcitool: Move gtk-vnc MinGW builds to Fedora Rawhide
by Andrea Bolognani
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
4 years, 7 months
[libvirt-perl PATCH v2 0/3] gitlab: introduce CI coverage
by Daniel P. Berrangé
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
4 years, 7 months
[libvirt-ci PATCH 0/2] Move MinGW builds back to Fedora Rawhide
by Andrea Bolognani
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
4 years, 7 months
[libvirt-ci PATCH] containers: New top-level directory
by Andrea Bolognani
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
4 years, 7 months
