|
Tried the patch series. Unfortunately I didn't get
the <rng> element reported in virsh capabilities, however I am not sure if this hardware (Lenovo T480) has a hardware RNG device to report anyways. I'll check it later when I have the chance. It is worth noticing that patch 3 is conflicting with current master. Extra code in qemu_driver.c that shifted the lines that the patch is changing (trivial) and, in qemu_conf.c, I had to change the call to virQEMUCapsFillDomainCaps since it is now taking an extra argument (added by 5b9819eedc). This change was enough to get the patch rolling: +++ b/src/qemu/qemu_conf.c @@ -1424,6 +1424,7 @@ virQEMUDriverGetDomainCapabilities(virQEMUDriverPtr driver, goto cleanup; if (virQEMUCapsFillDomainCaps(caps, domCaps, qemuCaps, + driver->privileged, cfg->firmwares, cfg->nfirmwares) < 0) goto cleanup; Thanks, DHB On 4/4/19 8:37 PM, Cole Robinson wrote:
I'm trying to remove some hurdles and pitfalls WRT extending domaincapabilities data. One issue is that it's too easy to add invalid data to it, or let the data become out of date. For example the first two patches of this series add <rng model=X> domcaps reporting. The logic to fill in the domcaps data from qemuCaps is nearly identical to the logic we use to validate rng->model in qemuDomainRNGDefValidate. If just those patches are added, and later a new qemu rng model was introduced, a future patch could easily miss updated domaincapabilities output. This series aims to set up a pattern to prevent these types of issues from sneaking in. A function virDomainCapsDeviceDefValidate is added which will use domcaps data to perform validation against a devicedef. The existing qemu <rng> model validation is moved there. This ensures that any future <rng> model additions, if they want to work in the qemu driver, effectively need to extend domaincapabilities as well. It's also theoretically useful for other drivers too. One issue is that at DomainDefValidate time we don't have domCaps handy, or any cache layer for domCaps assembling. Patch #4 adds a domCapsCache hashtable to the virQEMUCaps class for caching domCaps builds based on the full tuple of emulator+machine+arch+virttype. If qemuCaps need to be regenerated, the domCaps cache is wiped out for us so we don't need to worry about the data being stale, it's tied to the lifetime of a qemuCaps instance. Cole Robinson (7): conf: domcaps: Report device <rng> qemu: capabilities: fill in domcaps <rng> qemu: conf: add virQEMUDriverGetDomainCapabilities qemu: conf: Cache domCaps in qemuCaps conf: domcaps: Add virDomainCapsDeviceDefValidate qemu: domain: Call virDomainCapsDeviceDefValidate qemu: Move rng model validation to domcaps docs/formatdomaincaps.html.in | 35 ++++++++ docs/schemas/domaincaps.rng | 10 +++ src/conf/domain_capabilities.c | 83 ++++++++++++++++++ src/conf/domain_capabilities.h | 14 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 41 +++++++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_conf.c | 84 +++++++++++++++++++ src/qemu/qemu_conf.h | 7 ++ src/qemu/qemu_domain.c | 38 +++------ src/qemu/qemu_driver.c | 18 +--- .../qemu_1.7.0.x86_64.xml | 9 ++ .../qemu_2.12.0-virt.aarch64.xml | 11 +++ .../qemu_2.12.0.ppc64.xml | 11 +++ .../qemu_2.12.0.s390x.xml | 11 +++ .../qemu_2.12.0.x86_64.xml | 11 +++ .../qemu_2.6.0-virt.aarch64.xml | 11 +++ .../qemu_2.6.0.aarch64.xml | 11 +++ .../domaincapsschemadata/qemu_2.6.0.ppc64.xml | 11 +++ .../qemu_2.6.0.x86_64.xml | 11 +++ .../domaincapsschemadata/qemu_2.7.0.s390x.xml | 11 +++ .../qemu_2.8.0-tcg.x86_64.xml | 11 +++ .../domaincapsschemadata/qemu_2.8.0.s390x.xml | 11 +++ .../qemu_2.8.0.x86_64.xml | 11 +++ .../qemu_2.9.0-q35.x86_64.xml | 11 +++ .../qemu_2.9.0-tcg.x86_64.xml | 11 +++ .../qemu_2.9.0.x86_64.xml | 11 +++ .../domaincapsschemadata/qemu_3.0.0.s390x.xml | 11 +++ .../qemu_4.0.0.x86_64.xml | 11 +++ 29 files changed, 488 insertions(+), 40 deletions(-) |
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
