- 22 11月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
The qemu driver will obey <backingStore> when we support blockdev. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 21 11月, 2019 23 次提交
-
-
由 Christian Ehrhardt 提交于
Adding build time self tests for basic (deprecated), doorbell and plain mode. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
-
由 Jiri Denemark 提交于
When starting a domain without a CPU model specified in the domain XML, QEMU will choose a default one. Which is fine unless the domain gets migrated to another host because libvirt doesn't perform any CPU ABI checks and the virtual CPU provided by QEMU on the destination host can differ from the one on the source host. With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for a particular machine type and store it in the domain XML. This way the chosen CPU model is more visible to users and libvirt will make sure the guest will see the exact same CPU after migration. Architecture specific notes - aarch64: We only set the default CPU for TCG domains as KVM requires explicit "-cpu host" to work. - ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU, we will translate the default model to the model corresponding to the host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.). This is not a problem as the corresponding CPU model is in fact an alias for "host". This is probably not ideal, but it's not wrong and the default virtual CPU configured by libvirt is the same QEMU would use. TCG uses various CPU models depending on machine type and its version. - s390x: The default CPU for KVM is "host" while TCG defaults to "qemu". - x86_64: The default CPU model (qemu64) is not runnable on any host with KVM, but QEMU just disables unavailable features and starts happily. https://bugzilla.redhat.com/show_bug.cgi?id=1598151 https://bugzilla.redhat.com/show_bug.cgi?id=1598162Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
To avoid mismatch between host and QEMU capabilities. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Almost all TCG query-machines replies match KVM. The only exceptions are 4.2.0 replies on s390x which differ in the reported default CPU type. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
In preparation for making machine types dependent on the accelerator, the <machine> elements are formatted between <cpu type='kvm'> and <cpu type='tcg'>. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
It is a tiny wrapper around virQEMUCapsProbeQMPCPUDefinitions which will soon get private parameters and thus it cannot be exposed outside qemu_capabilities. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
We need to create a mapping between CPU model names and their corresponding QOM types. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
The functions return virDomainCapsCPUModelsPtr and thus they should be called *CPUModels for consistency. Functions called *CPUDefinitions will work on qemuMonitorCPUDefsPtr. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
While virDomainCapsCPUModel structure contains 'usable' field with virDomainCapsCPUUsable type, the lower level structure specific to QEMU driver used virTriStateBool for the same thing and we had to translate between them. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Let's store qemuMonitorCPUDefInfo directly in the array of CPUs in qemuMonitorCPUDefs rather then using an array of pointers. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
It is a container for a CPU models list (qemuMonitorCPUDefInfo) and a number of elements in this list. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Some callers of virQEMUCapsGetCPUDefinitions will need to filter the returned list of CPU models. Let's add the filtering parameters directly to virQEMUCapsGetCPUDefinitions to avoid copying the CPU models list twice. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Generated with "spapr/kvm: Set default cpu model for all machine classes" fix for QEMU applied. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 20 11月, 2019 4 次提交
-
-
由 Peter Krempa 提交于
We replaced them by use of transaction to simplify possible failure scenarios. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
testSchemaDir is a helper which invokes the schema test using virTestRun on all schema files. Since the function itself is not called inside virTestRun any helper function call is not dispatched to the user and thus it's hard to debug the test. Propagate errors from the directory traversal. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
In cases when we call a libvirt helper which reports an error the error would be hidden unless libvirt library debug is on. This produces a lot of output and is hard to debug. The helper provides a way to dispatch the libvirt error in specific cases sice we do already dispatch it in case when virTestRun is used. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Refactor various functions to avoid multiple freeing function calls. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 19 11月, 2019 2 次提交
-
-
由 Daniel Henrique Barboza 提交于
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
This flag is not implied by g_mkstemp_full, only by g_mkstemp. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reported-by: NBjoern Walk <bwalk@linux.ibm.com> Fixes: 4ac47730Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
- 15 11月, 2019 10 次提交
-
-
由 Pavel Hrdina 提交于
Glib implementation follows the ISO C99 standard so it's safe to replace the gnulib implementation. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Pavel Hrdina 提交于
We need to mock virCgroupV2DevicesAvailable() in order to remove any dependency on kernel as BPF devices might not be available. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Some of our tests try to validate domain XMLs they are working with (not intentionally, simply because they call top level domain XML parse function). Anyway, this implies that we build domain capabilities also - see virQEMUDriverGetDomainCapabilities(). And since some domain XMLs are type of 'kvm' the control gets through virQEMUCapsFillDomainCaps() and virHostCPUGetKVMMaxVCPUs() to opening /dev/kvm which may be missing on the machine we're running 'make check'. Previously, we did not see this issue, because it was masked. If building domain capabilities failed for whatever reason, we ignored the failure. Only v5.9.0-207-gc69e6ede uncovered the problem (it changed reval from 0 to -1 if virQEMUDriverGetDomainCapabilities() fails). Since the referenced commit is correct, we need to mock access to /dev/kvm in our tests. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
Some layered products such as oVirt have requested a way to avoid being blocked by guest agent commands when querying a loaded vm. For example, many guest agent commands are polled periodically to monitor changes, and rather than blocking the calling process, they'd prefer to simply time out when an agent query is taking too long. This patch adds a way for the user to specify a custom agent timeout that is applied to all agent commands. One special case to note here is the 'guest-sync' command. 'guest-sync' is issued internally prior to calling any other command. (For example, when libvirt wants to call 'guest-get-fsinfo', we first call 'guest-sync' and then call 'guest-get-fsinfo'). Previously, the 'guest-sync' command used a 5-second timeout (VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT), whereas the actual command that followed always blocked indefinitely (VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK). As part of this patch, if a custom timeout is specified that is shorter than 5 seconds, this new timeout is also used for 'guest-sync'. If there is no custom timeout or if the custom timeout is longer than 5 seconds, we will continue to use the 5-second timeout. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Prefer the GLib version to the one from gnulib. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Ján Tomko 提交于
With g_mkstemp_full, there is no need to distinguish between mkostemp and mkostemps (no suffix vs. a suffix of a fixed length), because the GLib function looks for the XXXXXX pattern everywhere in the string. Use S_IRUSR | S_IWUSR for the permissions and do not pass O_RDWR in flags since it's implied. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Ján Tomko 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Ján Tomko 提交于
The code using regexes got moved, but the include stayed. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Jonathon Jongsma 提交于
The 'ramfb' attribute provides a framebuffer to the guest that can be used as a boot display for the vgpu For example, the following configuration can be used to provide a vgpu with a boot display: <hostdev mode='subsystem' type='mdev' model='vfio-pci' display='on' ramfb='on'> <source> <address uuid='$UUID'/> </source> </hostdev> Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
由 Jonathon Jongsma 提交于
In a follow-up commit, we will use the domain capabilities to validate video device configurations, which means that we also need to make sure that the domain capabilities include the "none" video device. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-