[PATCH] docs: Clarify what source and name attributes of TPM profile describe
by Stefan Berger
Clarify what source and name attributes of TPM profile describe and
update the version placeholder to the libvirt version when profiles
were first supported, v10.10. Also mention that profiles with prefix
'custom:' in their name can be modified.
Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com>
---
docs/formatdomain.rst | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 60bee8bd4f..0a56a96ea4 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -8303,27 +8303,32 @@ Example: usage of external TPM emulator :since:`Since 9.0.0`
``profile``
The ``profile`` node is used to set a profile for a TPM 2.0 given in the
- source attribute. This profile will be set when the TPM is initially
- created and after that cannot be changed anymore. Once a profile has been
- set the name attribute will be updated with the name of the profile that
- is running. If no profile is provided, then swtpm will use the latest
- built-in 'default' profile or the default profile set in swtpm_setup.conf.
- Otherwise swtpm_setup will search for a profile with the given name with
- appended .json suffix in a configurable local and then in a distro
- directory. If none could be found in either, it will fall back trying to
- use a built-in one.
+ ``source`` attribute. This attribute describes the name of the file under
+ which the profile is stored, e.g. 'local:restricted' describes a locally
+ created profile with name 'restricted.json' that is found in the directory
+ pointed to by swtpm_setup.conf's local_profiles_dir. This profile will be set
+ when the TPM is initially created and after that the profile cannot be
+ changed anymore. Once a profile has been set, the ``name`` attribute will be
+ updated with the profile's name from its JSON description, for example
+ 'custom:restricted'. If no profile is provided, then swtpm will use the
+ latest built-in 'default' profile or the default profile set in
+ swtpm_setup.conf. Otherwise swtpm_setup will search for a profile with the
+ given name with appended .json suffix in a configurable local and then in a
+ distro directory. If none could be found in either, it will fall back trying
+ to use a built-in one.
The built-in 'null' profile provides backwards compatibility with
libtpms v0.9 but also restricts the user to use only TPM features that were
- available at the time of libtpms v0.9. The built-in 'custom' profile is the
- only profile that a user can modify and where the ``removeDisabled``
+ available at the time of libtpms v0.9. The built-in 'custom' profile, or
+ those with the prefix 'custom:' in the name, are the
+ only profiles that a user can modify and where the ``removeDisabled``
attribute has any effect. This attribute is particularly useful when a host
is running in FIPS mode and therefore some crypto algorithms (camellia,
tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are
disabled. When it is set to ``check`` (recommended) then only those
algorithms that are currently disabled will automatically be removed from
the 'custom' profile, while when it is set to ``fips-host`` then all
- potentially disabled algorithms will be removed. :since:`Since 10.??.0`
+ potentially disabled algorithms will be removed. :since:`Since 10.10.0`
TPM profiles provided by a distro can be referenced with the 'distro:'
prefix. Locally created TPM profiles can be referenced with the
--
2.47.1
1 week, 1 day
[PATCH 0/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Akio Kakuno
Hi, all.
- This patch adds Arm CCA support to qemu driver for aarch64 system.
CCA is an abbreviation for Arm Confidential Compute Architecture feature,
it enhances the virtualization capabilities of the platform by separating
the management of resources from access to those resources.
- We are not yet at the stage where we can merge this patch as host
linux/qemu suppor is no yet merged, but I would like to receive reviews
and comments on the overall direction.
[summary]
- At this stage, all you can do is getting the CCA capability with
the virsh domcapabilities command and start the CCA VM with the virsh
create command.
- capability info uses qemu QMP to query qemu options. The option that
exists now is for selecting a hash algorithm.
[Capability example]
- Execution results of 'virsh domcapability" on qemu
<domaincapabilities>
...
<features>
...
</sgx>
<cca supported='yes'>
<enum name='measurement-algo'>
<value>sha256</value>
<value>sha512</value>
</enum>
</cca>
<hyperv supported='yes'>
...
</features>
</domaincapabilities>
[XML example]
<domain>
...
<launchsecurity type='cca'>
<measurement-algo>sha256</measurement-algo>
</launchsecurity>
...
</domain>
[limitations/tests]
- To obtain capability info, it is necessary to support the qemu QMP
command, which qemu does not yet support. Therefore, I put a hack in
the code at hand and only confirmed the communication. Also, I think we
should check whether CPUFW supports CCA or not in qemu_firmware.c, but it
is not yet implemented.
- Verified that the CCA VM can be started from virsh create command.
[software version]
- I followed the steps in Linaro's blog below.
https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+...
- The Qemu used was based on Linaro's qemu(9.1.91).
https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/v3?ref_type=heads
Signed-off-by: Akio Kakuno <fj3333bs(a)fujitsu.com>
Best Regards.
Akio Kakuno (1):
RFC: Add Arm CCA support for getting capability information and
running Realm VM
docs/formatdomain.rst | 28 ++++++
docs/formatdomaincaps.rst | 26 ++++-
src/conf/domain_capabilities.c | 41 ++++++++
src/conf/domain_capabilities.h | 12 +++
src/conf/domain_conf.c | 13 +++
src/conf/domain_conf.h | 7 ++
src/conf/schemas/domaincaps.rng | 14 +++
src/conf/schemas/domaincommon.rng | 14 +++
src/conf/virconftypes.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 156 ++++++++++++++++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_cgroup.c | 2 +
src/qemu/qemu_command.c | 32 ++++++
src/qemu/qemu_driver.c | 2 +
src/qemu/qemu_monitor.c | 10 ++
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 104 ++++++++++++++++++++
src/qemu/qemu_monitor_json.h | 4 +
src/qemu/qemu_namespace.c | 2 +
src/qemu/qemu_process.c | 4 +
src/qemu/qemu_validate.c | 7 ++
22 files changed, 487 insertions(+), 1 deletion(-)
--
I previously posted this on the 25th, but it appears it didn't reach the mailing list. Apologies for any duplication.
2.34.1
1 week, 5 days
[PATCH 0/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Akio Kakuno
Hi, all.
- This patch adds Arm CCA support to qemu driver for aarch64 system.
CCA is an abbreviation for Arm Confidential Compute Architecture feature,
it enhances the virtualization capabilities of the platform by separating
the management of resources from access to those resources.
- We are not yet at the stage where we can merge this patch as host
linux/qemu suppor is no yet merged, but I would like to receive reviews
and comments on the overall direction.
[summary]
- At this stage, all you can do is getting the CCA capability with the virsh
domcapabilities command and start the CCA VM with the virsh create command.
- capability info uses qemu QMP to query qemu options. The option that
exists now is for selecting a hash algorithm.
[Capability example]
- Execution results of 'virsh domcapability" on qemu
<domaincapabilities>
...
<features>
...
</sgx>
<cca supported='yes'>
<enum name='measurement-algo'>
<value>sha256</value>
<value>sha512</value>
</enum>
</cca>
<hyperv supported='yes'>
...
</features>
</domaincapabilities>
[XML example]
<domain>
...
<launchsecurity type='cca'>
<measurement-algo>sha256</measurement-algo>
</launchsecurity>
...
</domain>
[limitations/tests]
- To obtain capability info, it is necessary to support the qemu QMP command,
which qemu does not yet support. Therefore, I put a hack in the code at
hand and only confirmed the communication. Also, I think we should check
whether CPUFW supports CCA or not in qemu_firmware.c, but it is not yet
implemented.
- Verified that the CCA VM can be started from virsh create command.
[software version]
- I followed the steps in Linaro's blog below.
https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+...
- The Qemu used was based on Linaro's qemu(9.1.91).
https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/v3?ref_type=heads
Signed-off-by: Akio Kakuno <fj3333bs(a)fujitsu.com>
Best Regards.
Akio Kakuno (1):
RFC: Add Arm CCA support for getting capability information and
running Realm VM
docs/formatdomain.rst | 28 ++++++
docs/formatdomaincaps.rst | 26 ++++-
src/conf/domain_capabilities.c | 41 ++++++++
src/conf/domain_capabilities.h | 12 +++
src/conf/domain_conf.c | 13 +++
src/conf/domain_conf.h | 7 ++
src/conf/schemas/domaincaps.rng | 14 +++
src/conf/schemas/domaincommon.rng | 14 +++
src/conf/virconftypes.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 156 ++++++++++++++++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_cgroup.c | 2 +
src/qemu/qemu_command.c | 32 ++++++
src/qemu/qemu_driver.c | 2 +
src/qemu/qemu_monitor.c | 10 ++
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 104 ++++++++++++++++++++
src/qemu/qemu_monitor_json.h | 4 +
src/qemu/qemu_namespace.c | 2 +
src/qemu/qemu_process.c | 4 +
src/qemu/qemu_validate.c | 7 ++
22 files changed, 487 insertions(+), 1 deletion(-)
--
2.34.1
1 week, 6 days
[RFC PATCH 0/5] qemu: Route hostdevs to multiple nested SMMUs
by Nathan Chen
Hi,
This is a draft solution for supporting multiple vSMMU instances in a qemu VM.
Based on discussions/suggestions received for a previous RFC by Nicolin here[0],
the association of vSMMUs to VFIO devices in VM PCIe topology should be moved
out of qemu into libvirt. In addition, the nested SMMU nodes should be passed
to qemu as pluggable devices.
To address these changes, this patch series introduces a new "nestedSmmuv3"
IOMMU model and "nestedSmmuv3" device type. Upon specifying the nestedSmmuv3
IOMMU model, nestedSmmuv3 devices will be auto-added to the VM definition based
on the available SMMU nodes in the host's sysfs. The nestedSmmuv3 devices will
each be attached to a separate PXB controller, and VFIO devices will be routed
to PXBs based on their association with host SMMU nodes. This will maintain a VM
PCIe topology that allows for multiple nested SMMUs per Nicolin's original qemu
patch series in [0] and Shameer's work in [1] to remove VM topology changes from
qemu and allow the nested SMMUs to be specified as pluggable devices.
For instance, if we specify the nestedSmmuv3 IOMMU model and a hostdev for
passthrough:
<devices>
<hostdev mode='subsystem' type='pci' managed='no'>
<source>
<address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/>
</source>
</hostdev>
<iommu model='nestedSmmuv3'/>
</devices>
Libvirt will scan sysfs and populate the VM definition with controllers and
nestedSmmuv3 devices based on host config. So if
/sys/bus/pci/devices/0009:01:00.0/iommu is a symlink to the host SMMU node
represented by
/sys/devices/platform/arm-smmu-v3.8.auto/iommu/smmu3.0x0000000016000000
and there are 3 host SMMU nodes under /sys/class/iommu/, we'll see three
auto-added nestedSmmuv3 devices, each routed to a pcie-expander-bus controller.
Then the hostdev will be routed to a PXB controller that has a matching host
SMMU node associated with it:
<devices>
...
<controller type='pci' index='1' model='pcie-expander-bus'>
<model name='pxb-pcie'/>
<target busNr='254'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</controller>
<controller type='pci' index='2' model='pcie-expander-bus'>
<model name='pxb-pcie'/>
<target busNr='251'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</controller>
<controller type='pci' index='3' model='pcie-expander-bus'>
<model name='pxb-pcie'/>
<target busNr='249'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</controller>
<controller type='pci' index='4' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='7' port='0x8'/>
<address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
</controller>
<hostdev mode='subsystem' type='pci' managed='no'>
<source>
<address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</hostdev>
<iommu model='nestedSmmuv3'/>
<nestedSmmuv3>
<name>smmu3.0x0000000012000000</name>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</nestedSmmuv3>
<nestedSmmuv3>
<name>smmu3.0x0000000016000000</name>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</nestedSmmuv3>
<nestedSmmuv3>
<name>smmu3.0x0000000011000000</name>
<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</nestedSmmuv3>
<iommu model='nestedSmmuv3'/>
</devices>
TODO:
- No DMA mapping can found by UEFI when specifying multiple passthrough devices
in the VM definition, and VM boot is subsequently blocked. We need to
investigate this for the next revision, but we don't encounter this issue when
passing through a single device. We'll include iommufd support in the next
revision to narrow down whether the required fix would be outside of libvirt.
- Shameer's qemu branch specifies nestedSmmuv3 bus number with "pci-bus"
instead of "bus", so the libvirt compilation test args and qemu args in
qemuBuildPCINestedSmmuv3DevProps() need to be modified to match this revision
of qemu. It will be reverted to using "bus" in the next qemu revision.
- This patchset decrements PXB busNr based on how many devices are attached
downstream, and the libvirt documentation states we must reserve busNr for the
PXB itself in addition to any devices attached downstream. When I launch a VM
and a PXB has a pcie-root-port and hostdev attached downstream, busNrs 253,
252, and 251 are reserved. But the PXB itself already has a bus number
assigned via the <address/> attribute, and I see 253 and 252 assigned to the
hostdev and pcie-root-port in the VM but not 251. Should we decrement busNr
based on libvirt documentation or do we only need two busNrs 253 and 252 in
the example here?
This series is on Github:
https://github.com/NathanChenNVIDIA/libvirt/tree/nested-smmuv3-12-05-24
Thanks,
Nathan
[0] https://lore.kernel.org/qemu-devel/cover.1719361174.git.nicolinc@nvidia.com/
[1] https://lore.kernel.org/qemu-devel/20241108125242.60136-1-shameerali.kolo...
Signed-off-by: Nathan Chen <nathanc(a)nvidia.com>
Nathan Chen (5):
conf: Add a nestedSmmuv3 IOMMU model
qemu: Implement and auto-add a nestedSmmuv3 device type
qemu: Create PXBs and auto-assign VFIO devs and nested SMMUs
qemu: Update PXB busNr for nestedSmmuv3 controllers
qemu: Add test case for specifying multiple nested SMMUs
docs/formatdomain.rst | 25 ++-
src/ch/ch_domain.c | 1 +
src/conf/domain_addr.c | 26 ++-
src/conf/domain_addr.h | 4 +-
src/conf/domain_conf.c | 188 +++++++++++++++++
src/conf/domain_conf.h | 15 ++
src/conf/domain_postparse.c | 1 +
src/conf/domain_validate.c | 24 +++
src/conf/schemas/domaincommon.rng | 17 ++
src/conf/virconftypes.h | 2 +
src/libvirt_private.syms | 2 +
src/lxc/lxc_driver.c | 6 +
src/qemu/qemu_command.c | 64 +++++-
src/qemu/qemu_command.h | 4 +
src/qemu/qemu_domain.c | 2 +
src/qemu/qemu_domain_address.c | 193 ++++++++++++++++++
src/qemu/qemu_driver.c | 3 +
src/qemu/qemu_hotplug.c | 5 +
src/qemu/qemu_postparse.c | 1 +
src/qemu/qemu_validate.c | 16 ++
src/test/test_driver.c | 4 +
tests/meson.build | 1 +
.../iommu-nestedsmmuv3.aarch64-latest.args | 38 ++++
.../iommu-nestedsmmuv3.aarch64-latest.xml | 61 ++++++
tests/qemuxmlconfdata/iommu-nestedsmmuv3.xml | 29 +++
tests/qemuxmlconftest.c | 4 +-
tests/schemas/device.rng.in | 1 +
tests/virnestedsmmuv3mock.c | 57 ++++++
28 files changed, 788 insertions(+), 6 deletions(-)
create mode 100644 tests/qemuxmlconfdata/iommu-nestedsmmuv3.aarch64-latest.args
create mode 100644 tests/qemuxmlconfdata/iommu-nestedsmmuv3.aarch64-latest.xml
create mode 100644 tests/qemuxmlconfdata/iommu-nestedsmmuv3.xml
create mode 100644 tests/virnestedsmmuv3mock.c
--
2.34.1
2 weeks
Investigating MAC Address Conflict Resolution in libvirt: Log
Analysis and Code Location Inquiry
by Xuda Zhang
Dear Team,
I am reaching out regarding an issue I encountered with libvirt and MAC
address conflicts. Below is a summary of the situation:
1. Initially, the vNIC's MAC address was different from the target VM's
MAC address.
2. After modifying the vNIC's MAC address to match the VM's MAC address,
the network was interrupted.
3. After rebooting the VM, the vNIC's MAC address was automatically
modified again.
I have observed the following kernel logs during this process:
Dec 24 16:59:40 zstack-manager kernel: br_enp2s0: port 14(vnic43.0)
entered disabled stateDec 24 16:59:40 zstack-manager kernel: device
vnic43.0 left promiscuous modeDec 24 16:59:40 zstack-manager kernel:
br_enp2s0: port 14(vnic43.0) entered disabled stateDec 24 17:00:11
zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocking
stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port
14(vnic43.0) entered disabled stateDec 24 17:00:11 zstack-manager
kernel: device vnic43.0 entered promiscuous modeDec 24 17:00:11
zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocking
stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port
14(vnic43.0) entered forwarding state
I am looking to understand the underlying code that handles the automatic
modification of the vNIC's MAC address after the conflict and how the
network interruption occurs. Can you help direct me to the relevant code
segment or provide any insights into this behavior?
Thank you for your assistance.
Best regards,
2 weeks
[PATCH 0/3] docs: Trivial cleanups
by Philippe Mathieu-Daudé
Philippe Mathieu-Daudé (3):
docs: Correct '-runas' and '-fsdev/-virtfs proxy' indentation
docs: Correct release of TCG trace-events removal
docs: Replace 'since' -> 'removed in' in removed-features.rst
docs/about/deprecated.rst | 2 +-
docs/about/removed-features.rst | 24 ++++++++++++------------
2 files changed, 13 insertions(+), 13 deletions(-)
--
2.47.1
2 weeks, 2 days
[RFC v2 PATCH 0/4] iproute2 bridge vlan support
by Leigh Brown
I have not had any feedback, but have been using this myself and
it works very nicely for me. I have updated the patch series to
allow vlans to be specified in network/portgroup definitions and
that functionality is working well.
All feedback gratefully received.
Description
-----------
The iproute2 bridge command supports the capability for VLAN filtering
that allows each interface connected to a standard linux bridge to be
configured to use one or more VLANs. For simple setups, this capability
is enough to allow virtual machines or containers to be put onto
separate VLANs without creating multiple bridges and VLANs on the host.
The first patch adds a new function virNetDevBridgeSetupVlans() that
will, given a virNetDevVlan structure, execute the required bridge vlan
commands to configure the given interface accordingly.
The second patch updates the virNetDevBridgeAddPort() function to allow
a virNetDevVlan parameter to be passed, and to call the
virNetDevBridgeSetupVlans() function.
The third patch updates the lxc and tap code to pass the virNetDevLan
parameter from the configuration and to update the XML domain and
network validation to permit the VLAN-related tags for standard
bridges.
The fourth patch updates documentation to match the new capability.
Changes since v1
----------------
- Fix bug in virNetDevSetupVlans where bridge port has no native vlan.
- Update bridge network validation to permit vlan configuration.
- Update documentation to match the functionality.
- Tweak some of the commit descriptions for clarity.
Usage example
-------------
Configure the host with systemd-networkd as follows:
/etc/systemd/network/br0.netdev (br0.network not shown)
[NetDev]
Name=br0
Kind=bridge
MACAddress=xx:xx:xx:xx:xx:xx
[Bridge]
VLANFiltering=on
/etc/systemd/network/eno1.network
[Match]
Name=eno1
[Network]
Bridge=br0
[Link]
MTUBytes=9000
[BridgeVLAN]
VLAN=40
[BridgeVLAN]
VLAN=60
Then add <vlan> tags into the lxc or qemu config:
lxc interface definition:
<interface type='bridge'>
<mac address='xx:xx:xx:xx:xx:xx'/>
<source bridge='br0'/>
<vlan>
<tag id='40'/>
</vlan>
</interface>
qemu interface definition:
<interface type='network'>
<mac address='xx:xx:xx:xx:xx:xx'/>
<source network='br0'/>
<vlan>
<tag id='60'/>
</vlan>
<model type='virtio'/>
<address type='pci' domain='0x0000'
bus='0x01' slot='0x00' function='0x0'/>
</interface>
Then, after starting them, you will see the following
$ sudo bridge vlan
port vlan-id
eno1 1 PVID Egress Untagged
40
60
br0 1 PVID Egress Untagged
vnet0 60 PVID Egress Untagged
vnet1 40 PVID Egress Untagged
Regards,
Leigh Brown (4):
util: Add virNetDevBridgeSetupVlans function
util: Add vlan support to virNetDevBridgeAddPort
Enable vlan support for standard linux bridges
docs: standard linux bridges now support vlans
docs/formatdomain.rst | 37 ++++++++++----------
docs/formatnetwork.rst | 45 ++++++++++++------------
meson.build | 1 +
src/conf/domain_validate.c | 3 +-
src/lxc/lxc_process.c | 3 +-
src/network/bridge_driver.c | 13 ++++---
src/util/virnetdevbridge.c | 68 ++++++++++++++++++++++++++++++++++---
src/util/virnetdevbridge.h | 4 ++-
src/util/virnetdevtap.c | 2 +-
9 files changed, 123 insertions(+), 53 deletions(-)
--
2.39.5
2 weeks, 2 days
[PATCH] spec: Enable ch driver
by Praveen K Paladugu
Enabling building and packaging ch driver in the spec file.
Signed-off-by: Praveen K Paladugu <praveenkpaladugu(a)gmail.com>
---
libvirt.spec.in | 51 ++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 3d5164b534..303d7cb34a 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -35,6 +35,7 @@
%define with_lxc 0%{!?_without_lxc:1}
%define with_libxl 0%{!?_without_libxl:1}
%define with_vbox 0%{!?_without_vbox:1}
+%define with_ch 0%{!?_without_ch:1}
%ifarch %{arches_qemu_kvm}
%define with_qemu_kvm %{with_qemu}
@@ -1026,6 +1027,20 @@ Server side daemon and driver required to manage the virtualization
capabilities of VirtualBox
%endif
+ %if %{with_ch}
+%package daemon-driver-ch
+Summary: Cloud-Hypervisor driver plugin for libvirtd daemon
+Requires: libvirt-daemon-common = %{version}-%{release}
+Requires: libvirt-daemon-log = %{version}-%{release}
+Requires: libvirt-libs = %{version}-%{release}
+
+%description daemon-driver-ch
+The ch driver plugin for the libvirtd daemon, providing
+an implementation of the hypervisor driver APIs by
+Cloud-Hypervisor
+ %endif
+
+
%package client
Summary: Client side utilities of the libvirt library
Requires: libvirt-libs = %{version}-%{release}
@@ -1188,9 +1203,15 @@ exit 1
%endif
%if %{with_esx}
- %define arg_esx -Ddriver_esx=enabled -Dcurl=enabled
+ %define arg_esx -Ddriver_esx=enabled
+%else
+ %define arg_esx -Ddriver_esx=disabled
+%endif
+
+%if %{with_esx} || %{with_ch}
+ %define arg_curl -Dcurl=enabled
%else
- %define arg_esx -Ddriver_esx=disabled -Dcurl=disabled
+ %define arg_curl -Dcurl=disabled
%endif
%if %{with_hyperv}
@@ -1205,6 +1226,12 @@ exit 1
%define arg_vmware -Ddriver_vmware=disabled
%endif
+%if %{with_ch}
+ %define arg_ch -Ddriver_ch=enabled
+%else
+ %define arg_ch -Ddriver_ch=disabled
+%endif
+
%if %{with_storage_rbd}
%define arg_storage_rbd -Dstorage_rbd=enabled
%else
@@ -1335,11 +1362,12 @@ export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/libvirt.spec)
-Ddriver_remote=enabled \
-Ddriver_test=enabled \
%{?arg_esx} \
+ %{?arg_curl} \
%{?arg_hyperv} \
%{?arg_vmware} \
+ %{?arg_ch} \
-Ddriver_vz=disabled \
-Ddriver_bhyve=disabled \
- -Ddriver_ch=disabled \
%{?arg_remote_mode} \
-Ddriver_interface=enabled \
-Ddriver_network=enabled \
@@ -1541,6 +1569,10 @@ rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.libxl
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_libxl.aug
rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_libxl.aug
%endif
+ %if ! %{with_ch}
+rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/libvirtd_ch.aug
+rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_ch.aug
+ %endif
# Copied into libvirt-docs subpackage eventually
mv $RPM_BUILD_ROOT%{_datadir}/doc/libvirt libvirt-docs
@@ -2405,6 +2437,19 @@ exit 0
%attr(0755, root, root) %{_libexecdir}/libvirt_sanlock_helper
%endif
+ %if %{with_ch}
+%files daemon-driver-ch
+%attr(0755, root, root) %{_sbindir}/virtchd
+%config(noreplace) %{_sysconfdir}/libvirt/virtchd.conf
+%{_datadir}/augeas/lenses/virtchd.aug
+%{_datadir}/augeas/lenses/tests/test_virtchd.aug
+%{_unitdir}/virtchd-admin.socket
+%{_unitdir}/virtchd-ro.socket
+%{_unitdir}/virtchd.service
+%{_unitdir}/virtchd.socket
+%{_libdir}/libvirt/connection-driver/libvirt_driver_ch.so
+ %endif
+
%files client
%{_mandir}/man1/virsh.1*
%{_mandir}/man1/virt-xml-validate.1*
--
2.47.0
2 weeks, 4 days
[PATCH] ch: implement domainInterfaceAddresses
by Praveen K Paladugu
From: Anirudh Rayabharam <anrayabh(a)linux.microsoft.com>
Implement domainInterfaceAddresses for the Cloud Hypervisor driver.
Support VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE and
VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP sources. Implementation is
similar to other drivers.
Signed-off-by: Anirudh Rayabharam <anrayabh(a)linux.microsoft.com>
Signed-off-by: Praveen K Paladugu <praveenkpaladugu(a)gmail.com>
---
src/ch/ch_driver.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/src/ch/ch_driver.c b/src/ch/ch_driver.c
index 6a8da5f356..d284524337 100644
--- a/src/ch/ch_driver.c
+++ b/src/ch/ch_driver.c
@@ -2298,6 +2298,47 @@ chConnectDomainEventDeregisterAny(virConnectPtr conn,
return 0;
}
+static int
+chDomainInterfaceAddresses(virDomain *dom,
+ virDomainInterfacePtr **ifaces,
+ unsigned int source,
+ unsigned int flags)
+{
+ virDomainObj *vm = NULL;
+ int ret = -1;
+
+ virCheckFlags(0, -1);
+
+ if (!(vm = virCHDomainObjFromDomain(dom)))
+ goto cleanup;
+
+ if (virDomainInterfaceAddressesEnsureACL(dom->conn, vm->def, source) < 0)
+ goto cleanup;
+
+ if (virDomainObjCheckActive(vm) < 0)
+ goto cleanup;
+
+ switch (source) {
+ case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE:
+ ret = virDomainNetDHCPInterfaces(vm->def, ifaces);
+ break;
+
+ case VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP:
+ ret = virDomainNetARPInterfaces(vm->def, ifaces);
+ break;
+
+ default:
+ virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED,
+ _("Unsupported IP address data source %1$d"),
+ source);
+ break;
+ }
+
+ cleanup:
+ virDomainObjEndAPI(&vm);
+ return ret;
+}
+
/* Function Tables */
static virHypervisorDriver chHypervisorDriver = {
@@ -2316,6 +2357,7 @@ static virHypervisorDriver chHypervisorDriver = {
.domainCreateXML = chDomainCreateXML, /* 7.5.0 */
.domainCreate = chDomainCreate, /* 7.5.0 */
.domainCreateWithFlags = chDomainCreateWithFlags, /* 7.5.0 */
+ .domainInterfaceAddresses = chDomainInterfaceAddresses, /* 10.10.1 */
.domainShutdown = chDomainShutdown, /* 7.5.0 */
.domainShutdownFlags = chDomainShutdownFlags, /* 7.5.0 */
.domainReboot = chDomainReboot, /* 7.5.0 */
--
2.47.0
2 weeks, 4 days
[PATCH 00/10] Enabling logging for ch guests
by Praveen K Paladugu
LogContext management is now moved from Qemu driver to hypervisor. After
migrating Qemu to use domain_logcontext, I extended ch driver to use also use
domain_logcontext to capture early boot failures within domain specific log
files.
Changes in V2:
* refactored the patches to ensure all of them build.
Praveen K Paladugu (10):
hypervisor: copy qemu log context mgmt to hypervisor
hypervisor: rename reference to qemu in domain_logcontext
hypervisor: drop qemu specific args in domainLogContextNew
hypervisor: Build domain_logcontext
libvirt_private: export symbols from domain_logcontext
qemu: Modify qemu driver to use domainLogContext
qemu: delete qemu_logcontext files
ch: Enable logging for ch domains
ch: move curl_data and curl_callback definitions
ch: Enable logging curl responses from ch
po/POTFILES | 2 +-
src/ch/ch_conf.h | 2 +
src/ch/ch_monitor.c | 84 ++++++++++++-------
src/ch/ch_monitor.h | 6 +-
src/ch/ch_process.c | 36 ++++++--
.../domain_logcontext.c} | 78 +++++++++--------
src/hypervisor/domain_logcontext.h | 45 ++++++++++
src/hypervisor/meson.build | 1 +
src/libvirt_private.syms | 6 ++
src/qemu/meson.build | 1 -
src/qemu/qemu_domain.c | 28 +++----
src/qemu/qemu_domain.h | 12 +--
src/qemu/qemu_logcontext.h | 41 ---------
src/qemu/qemu_nbdkit.c | 12 ++-
src/qemu/qemu_process.c | 45 +++++-----
15 files changed, 235 insertions(+), 164 deletions(-)
rename src/{qemu/qemu_logcontext.c => hypervisor/domain_logcontext.c} (79%)
create mode 100644 src/hypervisor/domain_logcontext.h
delete mode 100644 src/qemu/qemu_logcontext.h
--
2.47.0
2 weeks, 4 days
