- 04 5月, 2018 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 22 7月, 2017 1 次提交
-
-
由 dann frazier 提交于
Add a path for UEFI VMs for AArch32 VMs, based on the path Debian is using. libvirt is the de facto canonical location for defining where distros should place these firmware images, so let's define this path here to try and minimize distro fragmentation.
-
- 30 3月, 2017 1 次提交
-
-
由 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>
-
- 07 3月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 04 3月, 2017 3 次提交
-
-
由 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 提交于
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 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 28 11月, 2016 2 次提交
-
-
由 Jiri Denemark 提交于
QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 26 11月, 2016 2 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 22 9月, 2016 4 次提交
-
-
由 Jiri Denemark 提交于
The domain capabilities XML is capable of showing whether each guest CPU mode is supported or not with a possibility to provide additional details. This patch enhances host-model capability to advertise the exact CPU model which will be used as a host-model: <cpu> ... <mode name='host-model' supported='yes'> <model fallback='allow'>Broadwell</model> <vendor>Intel</vendor> <feature policy='disable' name='aes'/> <feature policy='require' name='vmx'/> </mode> ... </cpu> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
In case a hypervisor is able to tell us a list of supported CPU models and whether each CPU models can be used on the current host, we can propagate this to domain capabilities. This is a better alternative to calling virConnectCompareCPU for each supported CPU model. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The patch adds <cpu> element to domain capabilities XML: <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'/> <mode name='custom' supported='yes'> <model>Broadwell</model> <model>Broadwell-noTSX</model> ... </mode> </cpu> Applications can use it to inspect what CPU configuration modes are supported for a specific combination of domain type, emulator binary, guest architecture and machine type. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 24 5月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 16 5月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 10 5月, 2016 2 次提交
-
-
由 Cole Robinson 提交于
Requires adding the plumbing for <device><video> The value is <enum name='modelType'> to match the associated domain XML of <video><model type='XXX'/> Wire it up for qemu too
-
由 Cole Robinson 提交于
Requires adding the plumbing for <device><graphics> Wire it up for qemu too
-
- 06 5月, 2016 3 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Enhance the test to cover all capabilities we probe for rather than testing the flags only. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 20 4月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
Add information about GIC capabilities to virDomainCaps and update the formatter to include them in the XML output.
-
- 29 1月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
Well, even though users can pass the list of UEFI:NVRAM pairs at the configure time, we may maintain the list of widely available UEFI ourselves too. And as arm64 begin to rises, OVMF was ported there too. With a slight name change - it's called AAVMF, with AAVMF_CODE.fd being the UEFI firmware and AAVMF_VARS.fd being the NVRAM store file. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 9月, 2014 2 次提交
-
-
由 Michal Privoznik 提交于
Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
As of 54289916 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 03 7月, 2014 2 次提交
-
-
由 Michal Privoznik 提交于
So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This new module holds and formats capabilities for emulator. If you are about to create a new domain, you may want to know what is the host or hypervisor capable of. To make sure we don't regress on the XML, the formatting is not something left for each driver to implement, rather there's general format function. The domain capabilities is a lockable object (even though the locking is not necessary yet) which uses reference counter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-