- 18 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Introduce new wrapper functions without *Machine* in the function name that take the whole virDomainDef structure as argument and call the existing functions with *Machine* in the function name. Change the arguments of existing functions to *machine* and *arch* because they don't need the whole virDomainDef structure and they could be used in places where we don't have virDomainDef. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 13 4月, 2017 1 次提交
-
-
由 Ján Tomko 提交于
Do not probe for devices that QEMU does not know when probing for device options.
-
- 11 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
This removes the hacky extern global variable and modifies the test code to properly create QEMU capabilities cache for QEMU binaries used in our tests. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 07 4月, 2017 8 次提交
-
-
由 Jiri Denemark 提交于
This reverts commit 68507d77 which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit dfc711dc which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit 959e72d3 which was pushed accidentally.
-
由 Jiri Denemark 提交于
This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We will need to store two more host CPU models and nested structs look better than separate items with long complicated names. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 03 4月, 2017 3 次提交
-
-
由 Andrea Bolognani 提交于
So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
-
由 Andrea Bolognani 提交于
The capabilities used in test cases should match those used during normal operation for the tests to make any sense. This results in the generated command line for a few test cases (most notably non-x86 test cases that were wrongly assuming they could use -no-acpi) changing.
-
由 Andrea Bolognani 提交于
Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
-
- 30 3月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
CPU features which change their value from disabled to enabled between two calls to query-cpu-model-expansion (the first with no extra properties set and the second with 'migratable' property set to false) can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo. Since the code consuming qemuMonitorCPUModelInfo currently ignores the migratable flag, this change is effectively changing the CPU model advertised in domain capabilities to contain all features (even those which block migration). And this matches what we do for QEMU older than 2.9.0, when we detect all CPUID bits ourselves without asking QEMU. As a result of this change <cpu mode='host-model'> <feature name='invtsc' policy='require'/> </cpu> will work with all QEMU versions. Such CPU definition would be forbidden with QEMU >= 2.9.0 without this patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 3月, 2017 5 次提交
-
-
由 Martin Kletzander 提交于
This way more drivers can utilize the functionality without copying the code. And we can therefore test it in one place for all of them. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
There is no "node driver" as there was before, drivers have to do their own ACL checking anyway, so they all specify their functions and nodeinfo is basically just extending conf/capablities. Hence moving the code to src/conf/ is the right way to go. Also that way we can de-duplicate some code that is in virsysfs and/or virhostcpu that got duplicated during the virhostcpu.c split. And Some cleanup is done throughout the changes, like adding the vir* prefix etc. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Both QEMU and bhyve are using the same function for setting up the CPU in virCapabilities, so de-duplicate it, save code and time, and help other drivers adopt it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
The event is fired when a given block backend node (identified by the node name) experiences a write beyond the bound set via block-set-write-threshold QMP command. This wires up the monitor code to extract the data and allow us receiving the events and the capability.
-
- 23 3月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 17 3月, 2017 2 次提交
-
-
由 Guido Günther 提交于
This unbreaks emulators that don't support this command such as qemu-system-mips*. Reference: http://bugs.debian.org/854125
-
由 Andrea Bolognani 提交于
QEMU 2.9 introduces the pcie-root-port device, which is a generic version of the existing ioh3420 device. Make the new device available to libvirt users.
-
- 16 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
There were couple of reports on the list (e.g. [1]) that guests with huge amounts of RAM are unable to start because libvirt kills qemu in the initialization phase. The problem is that if guest is configured to use hugepages kernel has to zero them all out before handing over to qemu process. For instance, 402GiB worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we do not want to make the timeout for connecting to monitor configurable, we have to teach libvirt to count with this fact. This commit implements "1s per each 1GiB of RAM" approach as suggested here [2]. 1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html 2: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 3月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Introduce a qemu capability for -device nvdimm. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 14 3月, 2017 5 次提交
-
-
由 Jiri Denemark 提交于
One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function is now called virQEMUCapsProbeHostCPU. Both the refactoring and the change of the name is done for consistency with a new function which will be introduced in the following commit. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When creating host CPU definition usable with a given emulator, the CPU should not be defined using an unsupported CPU model. The new @models and @nmodels parameters can be used to limit CPU models which can be used in the result. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The parameter can be used to request either VIR_CPU_TYPE_HOST (which has been assumed so far) or VIR_CPU_TYPE_GUEST definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
cpuNodeData has always been followed by cpuDecode as no hypervisor driver is really interested in raw CPUID data for a host CPU. Let's create a new CPU driver API which returns virCPUDefPtr directly. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 3月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 06 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
The implementation matches virStringListFreeCount. The only difference between the two functions is the ordering of their parameters. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 3月, 2017 6 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-