- 21 9月, 2018 3 次提交
-
-
由 Andrea Bolognani 提交于
virCapabilitiesAddGuestDomain() takes an optional binary name: this is intended for cases where a certain domain type can't use the default one registered for the guest architecture, but has to use a special binary instead. The current code, however, will pass 'binary' again when 'kvmbin' is not defined, which is unnecessary as 'binary' has been registered as default earlier, and will result in capabilities output such as <emulator>/usr/bin/qemu-system-x86_64</emulator> <domain type='qemu'/> <domain type='kvm'> <emulator>/usr/bin/qemu-system-x86_64</emulator> </domain> with the second <emulator> element providing no additional information. Change it so that, when 'kvmbin' is not defined, NULL is passed and so the default emulator will be used instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
The function performing the checks, rather than its callers, should contain comments explaining the rationale behind said checks. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 John Ferlan 提交于
There seems to be no need to add the ignore_value wrapper or caste with (void) to the unlink() calls, so let's just remove them. I assume at one point in time Coverity complained. So, let's just be consistent - those that care to check the return status can and those that don't can just have the naked unlink. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 17 9月, 2018 4 次提交
-
-
由 Andrea Bolognani 提交于
The file being present doesn't necessarily mean anything these days, as it's created independently of whether the kvm module has been loaded[1]; moreover, we're already gathering all the information we need through QMP, so poking the filesystem at all is entirely unnecessary. [1] https://github.com/systemd/systemd/commit/d35d6249d5a7ed3228Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
This capability is documented as having one meaning (whether KVM is enabled by default) but is actually assigned two other meanings over its life: whether the query-kvm QMP command is available at first, and later on whether KVM is usable / was used during probing. Since the query-kvm QMP command was available in 1.5.0, we can avoid probing for it; additionally, we can simplify the logic by setting the flag when it applies instead of initially setting it and then clearing it when it doesn't. The flag's description is also updated to reflect reality. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
A side effect of recent changes is that we would always try to regenerate the capabilities cache for non-native QEMU binaries based on /dev/kvm availability, which is of course complete nonsense. Make sure that doesn't happen. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
It was already available in 1.5.0. Moreover, we're not even formatting it on the QEMU command line, ever: we just use it as part of some logic that decides whether KVM support should be advertised, and as it turns out that logic is actually buggy and dropping this capability fixes it. https://bugzilla.redhat.com/show_bug.cgi?id=1628469Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
- 13 9月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
After removing the host CPU model re-computation, this function is no longer necessary. This reverts commits: commit d0498881 virQEMUCapsFreeHostCPUModel: Don't always free host cpuData commit 5276ec71 testUpdateQEMUCaps: Don't leak host cpuData Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 12 9月, 2018 4 次提交
-
-
由 Andrea Bolognani 提交于
We require QEMU 1.5.0 these days, so checking for versions older than that is pointless. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
The capability was introduced in QEMU 1.5.0, which is our minimum supported QEMU version these days. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
The capability was introduced in QEMU 1.3.1 and we require QEMU 1.5.0 these days. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Commit 77f51ab5 started parsing an copying the SEV capabilities, but omitted the free call. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 07 9月, 2018 8 次提交
-
-
由 Ján Tomko 提交于
Previous commits removed all capabilities from per-device property probing for: pci-assign kvm-pci-assign usb-host scsi-generic Remove them from the virQEMUCapsDeviceProps list and get rid of the redundant device-list-properties QMP calls. Note that 'pci-assign' was already useless, because the QMP version of the device is called 'kvm-pci-assign', see libvirt commit 72574808 from 2012. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Introduced by QEMU commit 28b77657 in v1.0-rc4~21^2~8. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Introduced by QEMU commit c29029d which was included in 1.5.0 Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Added by QEMU commit 65bb3a5 contained in v1.1. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Added by QEMU commit 65bb3a5 contained in v1.1. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
At the time of the addition of 'pci-assign' in QEMU commit v1.3.0-rc0~572^2 the bootindex argument was already supported. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
At the time of the addition of 'pci-assign' in QEMU commit v1.3.0-rc0~572^2 the configfd argument was already supported. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Ján Tomko 提交于
Added by commit fc66c160 and not used since. Also, the device was present in QEMU 1.5.0 so this capability will not be needed if we ever decide to implement usb-net support. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 28 8月, 2018 3 次提交
-
-
由 Daniel P. Berrangé 提交于
Historically the argv -> xml convertor wanted the same default machine as we'd set when parsing xml. The latter has now changed, however, to use a default defined by libvirt. The former needs fixing to again honour the default QEMU machine. This exposed a bug in handling for the aarch64 target, as QEMU does not define any default machine. Thus we should not having been accepting argv without a -machine provided. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default machine any more, instead it gets the historical default that libvirt prefers for each arch. Rename it, so that the old name can be used for getting QEMU's default. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 24 8月, 2018 5 次提交
-
-
由 Peter Krempa 提交于
The capability was usable since qemu 1.3 so we can remove all the detection code. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Peter Krempa 提交于
For versions where we can probe that the arguments are optional we can perform the probing by a schema query rather than sending a separate command to do so. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Lubomir Rintel 提交于
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Lubomir Rintel 提交于
They're ARM specific. Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 21 8月, 2018 1 次提交
-
-
由 Peter Krempa 提交于
The capability currently is not enabled so that we can add individual bits first. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 20 8月, 2018 3 次提交
-
-
由 Erik Skultety 提交于
Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: NErik Skultety <eskultet@redhat.com> Acked-by: NPeter Krempa <pkrempa@redhat.com> Tested-by: NBrijesh Singh <brijesh.singh@amd.com>
-
由 Erik Skultety 提交于
So the procedure to detect SEV support works like this: 1) we detect that sev-guest is among the QOM types and set the cap flag 2) we probe the monitor for SEV support - this is tricky, because QEMU with compiled SEV support will always report -object sev-guest and query-sev-capabilities command, that however doesn't mean SEV is supported 3) depending on what the monitor returned, we either keep or clear the capability flag for SEV Commit a349c6c2 added an explicit check for "GenericError" in the monitor reply to prevent libvirtd to spam logs about missing 'query-sev-capabilities' command. At the same time though, it returned success in this case which means that we didn't clear the capability flag afterwards and happily formatted SEV into qemuCaps. Therefore, adjust all the relevant callers to handle -1 on errors, 0 on SEV being unsupported and 1 on SEV being supported. Signed-off-by: NErik Skultety <eskultet@redhat.com> Acked-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Erik Skultety 提交于
Keep with the recent effort of replacing as many explicit *Free functions with their automatic equivalents. Signed-off-by: NErik Skultety <eskultet@redhat.com> Acked-by: NPeter Krempa <pkrempa@redhat.com>
-
- 09 8月, 2018 1 次提交
-
-
由 Peter Krempa 提交于
The field was added in qemu v0.13.0-rc0-731-g1ca4d09ae0 so all supported qemu versions now use it. There's a LOT of test fallout as we did not use capabilities close enough to upstream for many of our tests. Several tests had a 'bootindex' variant. Since they'd become redundant they are also removed here. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 07 8月, 2018 1 次提交
-
-
由 Daniel P. Berrangé 提交于
It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 19 7月, 2018 2 次提交
-
-
由 Erik Skultety 提交于
QEMU 2.12 introduced a new vfio-pci device option 'display=on/off/auto'. This patch introduces the necessary capability. Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Erik Skultety 提交于
Since QEMU 2.10, it's possible to use a new type of display - egl-headless which uses drm nodes to provide OpenGL support. This patch adds a capability for that. However, since QEMU doesn't provide a QMP command to probe it, we have to base the capability on specific QEMU version. Acked-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 10 7月, 2018 1 次提交
-
-
由 Peter Krempa 提交于
Support for specifying it with the -device frontend was added recently. Add a capability for it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 03 7月, 2018 1 次提交
-
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 26 6月, 2018 1 次提交
-
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
- 14 6月, 2018 1 次提交
-
-
由 Ján Tomko 提交于
It is only used in one place. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NBrijesh Singh <brijesh.singh@amd.com> Tested-by: NBrijesh Singh <brijesh.singh@amd.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-