[PATCH v5 0/5] Adding POWER11 CPU Support
by Narayana Murty N
This patch series introduces the necessary changes to
support the POWER11 CPU and POWER11 host in libvirt.
Additionally, it updates the QEMU capabilities with
the latest QEMU version v10.0.0 to include power11
in the capabilities tests.During testing of v2 patches
found a bug in qemu which sets wrong default cpu for
pre-9.0 machines, that was fixed in qemu v10.0.0.
Patch Summary:
Patch 0001: tests: Pin pseries-2.7 tests to the version 7.0.
Patch 0002: Fix: qemuhotplugtest Set the cpu version at source as POWER9.
Patch 0003: Add capabilities test support for QEMU 10.0.0 on PPC64.
Patch 0004: Add POWER11 CPU model support.
Patch 0005: Add POWER11 host model support.
The corresponding patches for the Linux kernel and QEMU
are already upstream. Relevant links are provided below:
Linux kernel patches:
1. Linux P11 support: commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode")
2. Linux P11 KVM support: commit 96e266e3bcd6 ("KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests")
Qemu patches:
3. Qemu P11 support: commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type")
4. Qemu P11 DD02.0 support: commit c0d964076c3e ("target/ppc: Add Power11 DD2.0 processor")
5. Qemu pre-9.0 pseries michines changing default cpu with Qemu commit 1490d0bcdfcb ("ppc/spapr: fix default cpu for pre-9.0 machines.").
Note on CPU model naming:
From the discussion in the community thread
(https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IC...),
we will continue using the uppercase only for POWER11 for the CPU model name.
This is consistent with the naming convention used for existing POWER models
(e.g., POWER9, POWER10) in libvirt's CPU map and avoids compatibility issues
with existing tooling and test expectations.
Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com>
----
Changelog:
-V4: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/IC...
*Continue to use POWER11 in uppercase, following feedback.
*Test data caps_10.0.0.ppc64.replies generated with QEMU v10.0.0.
-V3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PG...
*Rebased to top of the tree as I saw some tests were failing with
recent commits.
-V2:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/JQ5UJFWJG35OFX54RQIDHFUSX3RIYIYP/?sort=thread
*Instead of removing pseries-2.7 related tests, they are now pinned to the latest available capabilities version 7.0.0.
*patch0003: description explained why the cpu version changed.
*change the cpu model name to lower case.
*Fixing the hotplugtest by setting the cpu version at source as POWER9
*default CPU change for pseries machines preior to pseries-9.0 tests cases for tcg fixed.
* Fixing the compat models check for host CPU names in both lowercase and uppercase.
-V1:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4A3IND2QP5CE654XE755ICRZKLUNYXAE/
*Addressed v2 patch readability issues.
Narayana Murty N (5):
tests: Pin pseries-2.7 tests to the version 7.0
tests: qemuhotplugtest: Set the cpu version at source for PPC64 tests
tests: Add capabilities for QEMU 10.0.0 on ppc64
cpu_map: Add POWER11 CPU model support
cpu_ppc64: Add POWER11 host-model support
src/cpu/cpu_ppc64.c | 8 +-
src/cpu_map/index.xml | 1 +
src/cpu_map/meson.build | 1 +
src/cpu_map/ppc64_POWER11.xml | 6 +
tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 191 +
.../caps_10.0.0_ppc64.replies | 39513 ++++++++++++++++
.../caps_10.0.0_ppc64.xml | 1088 +
.../ppc64-modern-bulk-domain.xml | 3 +-
.../ppc64-modern-individual-domain.xml | 3 +-
.../disk-floppy-pseries.ppc64-latest.xml | 2 +-
.../memory-hotplug-nvdimm-ppc64.xml | 3 +-
.../memory-hotplug-ppc64-nonuma.xml | 3 +
.../panic-pseries.ppc64-latest.args | 2 +-
.../panic-pseries.ppc64-latest.xml | 2 +-
...ault-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} | 0
...fault-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} | 0
...ault-cpu-kvm-pseries-3.1.ppc64-latest.args | 2 +-
...fault-cpu-kvm-pseries-3.1.ppc64-latest.xml | 2 +-
...ault-cpu-kvm-pseries-4.2.ppc64-latest.args | 2 +-
...fault-cpu-kvm-pseries-4.2.ppc64-latest.xml | 2 +-
...ault-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} | 0
...fault-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} | 0
...efault-models.ppc64-latest.abi-update.args | 4 +-
...default-models.ppc64-latest.abi-update.xml | 2 +-
...4-pseries-default-models.ppc64-latest.args | 4 +-
...64-pseries-default-models.ppc64-latest.xml | 2 +-
.../ppc64-pseries-graphics.ppc64-latest.args | 4 +-
.../ppc64-pseries-graphics.ppc64-latest.xml | 2 +-
.../ppc64-pseries-headless.ppc64-latest.args | 4 +-
.../ppc64-pseries-headless.ppc64-latest.xml | 2 +-
...eries-minimal.ppc64-latest.abi-update.args | 2 +-
...series-minimal.ppc64-latest.abi-update.xml | 2 +-
.../ppc64-pseries-minimal.ppc64-latest.args | 2 +-
.../ppc64-pseries-minimal.ppc64-latest.xml | 2 +-
.../ppc64-tpmproxy-single.ppc64-latest.args | 2 +-
.../ppc64-tpmproxy-single.ppc64-latest.xml | 2 +-
.../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 2 +-
.../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 2 +-
.../pseries-basic.ppc64-latest.args | 2 +-
.../pseries-basic.ppc64-latest.xml | 2 +-
.../pseries-console-virtio.ppc64-latest.args | 2 +-
.../pseries-console-virtio.ppc64-latest.xml | 2 +-
...eries-cpu-compat-power11.ppc64-latest.args | 31 +
...series-cpu-compat-power11.ppc64-latest.err | 1 +
...series-cpu-compat-power11.ppc64-latest.xml | 29 +
.../pseries-cpu-compat-power11.xml | 19 +
.../pseries-cpu-le.ppc64-latest.args | 2 +-
.../pseries-cpu-le.ppc64-latest.xml | 2 +-
.../pseries-features.ppc64-latest.args | 2 +-
.../pseries-features.ppc64-latest.xml | 2 +-
.../pseries-hostdevs-1.ppc64-latest.args | 2 +-
.../pseries-hostdevs-1.ppc64-latest.xml | 2 +-
.../pseries-hostdevs-2.ppc64-latest.args | 2 +-
.../pseries-hostdevs-2.ppc64-latest.xml | 2 +-
.../pseries-hostdevs-3.ppc64-latest.args | 2 +-
.../pseries-hostdevs-3.ppc64-latest.xml | 2 +-
.../pseries-many-buses-1.ppc64-latest.args | 2 +-
.../pseries-many-buses-1.ppc64-latest.xml | 2 +-
.../pseries-many-buses-2.ppc64-latest.args | 2 +-
.../pseries-many-buses-2.ppc64-latest.xml | 2 +-
.../pseries-many-devices.ppc64-latest.args | 2 +-
.../pseries-many-devices.ppc64-latest.xml | 2 +-
.../pseries-nvram.ppc64-latest.args | 2 +-
.../pseries-nvram.ppc64-latest.xml | 2 +-
.../pseries-panic-missing.ppc64-latest.args | 2 +-
.../pseries-panic-missing.ppc64-latest.xml | 2 +-
...pseries-panic-no-address.ppc64-latest.args | 2 +-
.../pseries-panic-no-address.ppc64-latest.xml | 2 +-
...ries-phb-default-missing.ppc64-latest.args | 2 +-
...eries-phb-default-missing.ppc64-latest.xml | 2 +-
.../pseries-phb-numa-node.ppc64-latest.args | 2 +-
.../pseries-phb-numa-node.ppc64-latest.xml | 2 +-
.../pseries-phb-simple.ppc64-latest.args | 6 +-
.../pseries-phb-simple.ppc64-latest.xml | 2 +-
.../pseries-phb-user-alias.ppc64-latest.args | 6 +-
.../pseries-phb-user-alias.ppc64-latest.xml | 2 +-
.../pseries-serial-native.ppc64-latest.args | 2 +-
.../pseries-serial-native.ppc64-latest.xml | 2 +-
.../pseries-serial-pci.ppc64-latest.args | 2 +-
.../pseries-serial-pci.ppc64-latest.xml | 2 +-
.../pseries-serial-usb.ppc64-latest.args | 2 +-
.../pseries-serial-usb.ppc64-latest.xml | 2 +-
.../pseries-usb-default.ppc64-latest.args | 2 +-
.../pseries-usb-default.ppc64-latest.xml | 2 +-
.../pseries-usb-kbd.ppc64-latest.args | 2 +-
.../pseries-usb-kbd.ppc64-latest.xml | 2 +-
.../pseries-usb-multi.ppc64-latest.args | 2 +-
.../pseries-usb-multi.ppc64-latest.xml | 2 +-
...series-vio-user-assigned.ppc64-latest.args | 7 +-
...pseries-vio-user-assigned.ppc64-latest.xml | 2 +-
.../pseries-vio.ppc64-latest.args | 7 +-
.../pseries-vio.ppc64-latest.xml | 2 +-
...fault-pseries.ppc64-latest.abi-update.args | 2 +-
...efault-pseries.ppc64-latest.abi-update.xml | 2 +-
...ntroller-default-pseries.ppc64-latest.args | 2 +-
...ontroller-default-pseries.ppc64-latest.xml | 2 +-
...fault-unavailable-pseries.ppc64-latest.xml | 2 +-
tests/qemuxmlconftest.c | 8 +-
tests/testutilshostcpus.h | 11 +
tests/testutilsqemu.c | 4 +
tests/testutilsqemu.h | 1 +
101 files changed, 41005 insertions(+), 101 deletions(-)
create mode 100644 src/cpu_map/ppc64_POWER11.xml
create mode 100644 tests/domaincapsdata/qemu_10.0.0.ppc64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.xml
rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} (100%)
rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} (100%)
rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} (100%)
rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} (100%)
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.args
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.err
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.xml
create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.xml
--
2.48.1
1 week
[PATCH] docs: domain: Explain supported options of 'error_policy'
by Peter Krempa
From: Peter Krempa <pkrempa(a)redhat.com>
Explain what the individual settings actually result in. The changes
are based on the paraprhase of qemu documentation which in
'qemu-options.hx' states:
``werror=action,rerror=action``
Specify which action to take on write and read errors. Valid
actions are: "ignore" (ignore the error and try to continue),
"stop" (pause QEMU), "report" (report the error to the guest),
"enospc" (pause QEMU only if the host disk is full; report the
error to the guest otherwise). The default setting is
``werror=enospc`` and ``rerror=report``.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/138
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
docs/formatdomain.rst | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index c7c75ae219..a23a746229 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -3451,8 +3451,12 @@ paravirtualized driver is specified via the ``disk`` element.
and sync requests from guest are ignored).
:since:`Since 0.6.0`
- The optional ``error_policy`` attribute controls how the hypervisor will
- behave on a disk read or write error, possible values are "stop",
- "report" (:since:`since 0.9.7`), "ignore", and "enospace".
+ behave on a disk read or write error, possible values are ``stop`` (
+ suspend/pause the domain on error), ``report`` (report the error to the
+ guest OS; :since:`since 0.9.7`), ``ignore`` (ignore the error and try to
+ continue), and ``enospace`` (suspend/pause the domain only if host storage
+ is full; report the error to the guest OS otherwise).
+
The default is left to the discretion of the hypervisor.
:since:`Since 0.8.0`.
- The optional ``rerror_policy`` attribute controls behavior for read
--
2.49.0
1 week
[PATCH v2 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
v2
- changed behavior from disabling features on the host model to
instead flagging the guest CPU to disable deprecated features
- removed disabling deprecated features on host model in
virQEMUCapsInitCPUModelS390
- added flagging deprecated_feats in qemuProcessUpdateGuestCPU
- added tests for deprecated_features='on'
- split virQEMUCapsUpdateCPUDeprecatedFeatures update and
qemuProcessUpdateGuestCPU changes
The intention of reporting deprecated features and modifying the guest
CPU model was to alleviate the user from the burden of preparing a guest
with the necessary amendments to assure migration to newer hardware.
While that goal was met by way of the "deprecated_features='on|off'"
attribute, it still adds an extra step that the user must be aware to
prepare a guest for migration and the errors that stem from an
unsuccessful migration (due to feature incompatibility) is not always
clear how to resolve.
These patches make s390 CPU host models migration ready from the get-go
by disabling deprecated features by default. They may still be disabled
for other model types via the respective attribute, or reenabled if
desired.
Collin Walling (3):
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: process: refactor deprecated features code
qemu: process: disable deprecated features for s390 models by default
src/qemu/qemu_capabilities.c | 6 ++--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_process.c | 30 ++++++++++++-----
...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++
...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++
.../cpu-model-deprecated-features-on.xml | 15 +++++++++
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 1 +
14 files changed, 108 insertions(+), 19 deletions(-)
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml
--
2.47.1
1 week, 1 day
RFC: schemas: resolving path type inconsistency in XML schemas
by Kirill Shchetiniuk
Hello everyone,
Sometime ago I sent a patch changing the XML schema to add GTK support for libvirt. As the type for one path argument, I used the <text/> type, simply copying the similar approach from another place in the XML schema definition. I was told that it's not the best way to use the <text/> type for paths and that absFilePath, a defined basic type for paths, should be used instead.
After this, I decided to fix this in a place where I had seen the same approach, too. After further investigation, I found a lot more places where the <text/> type is used for paths. Moreover, I found out that we have at least 4 type definitions for paths (files and directories). Some of these types accept simply everything, others paths starting with "/" or even Windows-style disk names.
<define name="filePath">
<data type="string">
<param name="pattern">.+</param>
</data>
</define>
<define name="dirPath">
<data type="string">
<param name="pattern">.+</param>
</data>
</define>
<define name="absFilePath">
<data type="string">
<param name="pattern">(/|[a-zA-Z]:\\).+</param>
</data>
</define>
<define name="absDirPath">
<data type="string">
<param name="pattern">/.*</param>
</data>
</define>
According to this, I have the following questions:
1. Do we allow users to use relative paths, or MUST all paths be absolute?
2. Do we have to accept Windows-style paths everywhere?
3. Do we need to have different types for directories? For example, in some places, the filePath type is used for directory parameters.
And as a last question, do we want to unify the basic types related to paths to maintain the schemas more consistent?
Kirill
1 week, 1 day
[PATCH 0/2] qemu: monitor: Fix handling of 'detach' for 'migrate' and 'dump-guest-memory' QMP commands
by Peter Krempa
QEMU is deprecating 'detach' argument of 'migrate' as it was never
actually used. Drop it in libvirt as we always specify it.
The monitor handler of 'dump-guest-memory' allows controlling 'detach'
but always passes true. Libvirt doesn't want to block the monitor so
hardcode 'true' in the monitor code instead.
Peter Krempa (2):
qemuMonitorDumpToFd: Drop 'detach' argument
qemuMonitorJSONMigrate: Drop 'detach' QMP option
src/qemu/qemu_driver.c | 2 +-
src/qemu/qemu_monitor.c | 5 ++---
src/qemu/qemu_monitor.h | 3 +--
src/qemu/qemu_monitor_json.c | 6 ++----
src/qemu/qemu_monitor_json.h | 3 +--
tests/qemumonitorjsontest.c | 3 +--
6 files changed, 8 insertions(+), 14 deletions(-)
--
2.49.0
1 week, 2 days
[PATCH 0/1] [RFC] Live migration support for ch driver
by Stefan Kober
This change serves as a proof of concept that adds live migration support to
the Cloud Hypervisor driver. It is meant to show feasibility and to receive
early feedback.
I tested the live migration by invoking:
virsh -c ch:///session migrate --domain vmName --desturi ch+ssh://dstHost/session --live
Opens:
* What is required for a minimal viable live migration to be merged?
* Job state tracking? (virDomainObjBeginJob, ...)
* What should 'virsh domjobinfo' show?
* Testing?
* Anything else?
Stefan Kober (1):
Initial CH migrate API
src/ch/ch_conf.h | 4 +
src/ch/ch_domain.h | 2 +
src/ch/ch_driver.c | 362 +++++++++++++++++++++++++++++-
src/ch/ch_monitor.c | 156 +++++++++++++
src/ch/ch_monitor.h | 8 +
src/ch/ch_process.c | 136 ++++++++++-
src/ch/ch_process.h | 6 +
src/hypervisor/domain_interface.c | 1 +
src/libvirt-domain.c | 15 +-
9 files changed, 680 insertions(+), 10 deletions(-)
--
2.49.0
1 week, 2 days
[PATCH] build-aux: simplify grep detection on FreeBSD
by Roman Bogorodskiy
From: Alexey Dokuchaev <danfe(a)FreeBSD.org>
For quite some time now FreeBSD provides its own version of the grep(1)
tool, and the GNU grep from the ports collection is available as
ggrep(1). So remove the detection code and just request ggrep.
Signed-off-by: Alexey Dokuchaev <danfe(a)FreeBSD.org>
---
build-aux/meson.build | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/build-aux/meson.build b/build-aux/meson.build
index bcd10e89f2..56c91971cf 100644
--- a/build-aux/meson.build
+++ b/build-aux/meson.build
@@ -13,23 +13,10 @@ if git and tests_enabled[0]
if host_machine.system() == 'freebsd' or host_machine.system() == 'darwin'
make_prog = find_program('gmake')
sed_prog = find_program('gsed')
+ grep_prog = find_program('ggrep')
else
make_prog = find_program('make')
sed_prog = find_program('sed')
- endif
-
- if host_machine.system() == 'freebsd'
- grep_prog = find_program('grep')
- grep_cmd = run_command(grep_prog, '--version', check: true)
- if grep_cmd.stdout().startswith('grep (BSD grep')
- grep_prog = find_program('/usr/local/bin/grep', required: false)
- if not grep_prog.found()
- error('GNU grep not found')
- endif
- endif
- elif host_machine.system() == 'darwin'
- grep_prog = find_program('ggrep')
- else
grep_prog = find_program('grep')
endif
--
2.49.0
1 week, 2 days
[PATCH 1/2] NEWS: bhyve: document NVRAM support
by Roman Bogorodskiy
Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com>
---
NEWS.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index e924c08fbf..102e49373a 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -23,6 +23,14 @@ v11.4.0 (unreleased)
That option suppresses registration of pkttyagent with polkitd.
+ * bhyve: support NVRAM configuration for UEFI firmwares
+
+ The bhyve driver now supports specifying NVRAM store file, such as ::
+
+ <os firmware='efi'>
+ <nvram/>
+ </os>
+
* **Bug fixes**
* qemu: Fix failure when reverting to internal snapshots
--
2.49.0
1 week, 2 days
[PATCH 0/4] USB hostdev: allow addressing by port
by Maximilian Martin
This resubmission splits up the previous patch into multiple patches and
incorporates review comments from Michal Prívozník.
Currently, only vendor/product and bus/device matching are supported for USB host
devices. Neither of these provide a stable and persistent way of assigning a guest
a specific host device. Vendor/product can be ambiguous. Device numbers change on
every enumeration.
This patch adds a bus/port matching, which allows a specific port on the host to be
specified using the dotted notation found in Linux's "devpath" sysfs attribute.
This patch is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7...
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513
Signed-off-by: Maximilian Martin <maximilian_martin(a)gmx.de>
Maximilian Martin (4):
virusb test data: add devpath files for port addressing
domain_conf, virhostdev, virusb, virusb test: add bus/port matching
schema: add USB port attribute
docs: add description for USB port matching
docs/formatdomain.rst | 29 ++--
src/conf/domain_conf.c | 69 +++++++-
src/conf/domain_conf.h | 1 +
src/conf/schemas/domaincommon.rng | 11 +-
src/hypervisor/virhostdev.c | 131 +++++++++------
src/libvirt_private.syms | 2 -
src/util/virusb.c | 156 ++++++------------
src/util/virusb.h | 32 ++--
tests/virusbtest.c | 149 ++++++++++++-----
.../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.3/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.4/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.5/devpath | 1 +
.../sys_bus_usb/devices/1-1.5.6/devpath | 1 +
.../sys_bus_usb/devices/1-1.5/devpath | 1 +
.../sys_bus_usb/devices/1-1.6/devpath | 1 +
.../sys_bus_usb/devices/1-1/devpath | 1 +
.../sys_bus_usb/devices/2-1.2/devpath | 1 +
.../sys_bus_usb/devices/2-1/devpath | 1 +
.../sys_bus_usb/devices/usb1/devpath | 1 +
.../sys_bus_usb/devices/usb2/devpath | 1 +
.../sys_bus_usb/devices/usb3/devpath | 1 +
.../sys_bus_usb/devices/usb4/devpath | 1 +
24 files changed, 351 insertions(+), 244 deletions(-)
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath
create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath
--
2.39.5
1 week, 2 days
[PATCH 0/5] bhyve: introduce NVRAM support
by Roman Bogorodskiy
Roman Bogorodskiy (5):
bhyve: conf: introduce nvramDir
bhyve: generate NVRAM bhyve arguments
bhyve: firmware: try to guess NVRAM settings
bhyve: introduce bhyveDomainDefValidate()
bhyve: support removing NVRAM on domain undefine
src/bhyve/bhyve_command.c | 8 +-
src/bhyve/bhyve_conf.c | 4 +
src/bhyve/bhyve_domain.c | 43 ++++++
src/bhyve/bhyve_driver.c | 32 ++++-
src/bhyve/bhyve_firmware.c | 119 ++++++++++++++--
src/bhyve/bhyve_process.c | 132 ++++++++++++++++++
src/bhyve/bhyve_process.h | 8 ++
src/bhyve/bhyve_utils.h | 2 +
src/bhyve/meson.build | 5 +
...gv-uefi-nvram-template-and-source-set.args | 12 ++
...-uefi-nvram-template-and-source-set.ldargs | 1 +
...rgv-uefi-nvram-template-and-source-set.xml | 24 ++++
...bhyvexml2argv-uefi-nvram-template-set.args | 12 ++
...yvexml2argv-uefi-nvram-template-set.ldargs | 1 +
.../bhyvexml2argv-uefi-nvram-template-set.xml | 24 ++++
.../bhyvexml2argv-uefi-nvram.args | 12 ++
.../bhyvexml2argv-uefi-nvram.ldargs | 1 +
.../bhyvexml2argv-uefi-nvram.xml | 24 ++++
tests/bhyvexml2argvtest.c | 5 +
19 files changed, 452 insertions(+), 17 deletions(-)
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.xml
--
2.49.0
1 week, 2 days
