- 02 7月, 2015 21 次提交
-
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Inheritance among CPU model is cool but it makes reviewing CPU model definitions and comparing them to CPU models from QEMU rather hard and unpleasant. Let's define all CPU models from scratch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Sorted feature list is easier to review or compare. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 30 6月, 2015 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 30 4月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=858147Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 26 3月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
QEMU 2.3 adds these new models to cover Haswell and Broadwell CPUs with updated microcode. Luckily, they also reverted former the machine type specific changes to existing models. And since these changes were never released, we don't need to hack around them in libvirt. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 23 3月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
Wikipedia's list of common misspellings [1] has a machine-readable version. This patch fixes those misspellings mentioned in the list which don't have multiple right variants (as e.g. "accension", which can be both "accession" and "ascension"), such misspellings are left untouched. The list of changes was manually re-checked for false positives. [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 02 3月, 2015 2 次提交
- 21 2月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
For historical reasons data regarding NUMA configuration were split between the CPU definition and numatune. We cannot do anything about the XML still being split, but we certainly can at least store the relevant data in one place. This patch moves the NUMA stuff to the right place.
-
- 19 2月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
Not all files we want to find using virFileFindResource{,Full} are generated when libvirt is built, some of them (such as RNG schemas) are distributed with sources. The current API was not able to find source files if libvirt was built in VPATH. Both RNG schemas and cpu_map.xml are distributed in source tarball. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 2月, 2015 1 次提交
-
-
由 Olivia Yin 提交于
With this patch, Freescale ppc64 CPU modesl could be recognized. virsh # cpu-models ppc64 POWERPC_e6500 POWERPC_e5500 power8 power8e power7+ power7 power6 POWER8_v1.0 POWER7+_v2.1 POWER7_v2.3 POWER7_v2.1 POWER7 virsh # capabilities <capabilities> <host> <uuid>5a54efa6-20dc-4da7-b271-0b7fb7062cb8</uuid> <cpu> <arch>ppc64</arch> <model>POWERPC_e6500</model> <vendor>Freescale</vendor>
-
- 14 1月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
The virCPUDefFormat* methods were relying on the VIR_DOMAIN_XML_* flag definitions. It is not desirable for low level internal functions to be coupled to flags for the public API, since they may need to be called from several different contexts where the flags would not be appropriate.
-
- 12 1月, 2015 1 次提交
-
-
由 Daniel Hansel 提交于
The curent libvirt CPU driver for s390 does not return a host CPU model. This patch returns 'host' according to the other platforms that would not decode any CPU model. This is an intermediate bugfix due to a discussion on OpenStack mailing list. The final patch introducing the CPU model support for s390x will exchange the hard-coded decode method. Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
-
- 04 12月, 2014 1 次提交
-
-
由 Pavel Hrdina 提交于
Commit 86a15a25 introduced a new cpu driver API 'getModels'. Public API allow you to pass NULL for models to get only number of existing models. However the new code will crash with segfault so we have to count with the possibility that the user wants only the number. There is also difference in order of the models gathered by this new API as the old approach was inserting the elements to the end of the array so we should use 'VIR_APPEND_ELEMENT'. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 03 12月, 2014 1 次提交
-
-
由 Daniel Hansel 提交于
For Intel and PowerPC the implementation is calling a cpu driver function across driver layers (i.e. from qemu driver directly to cpu driver). The correct behavior is to use libvirt API functionality to perform such a inter-driver call. This patch introduces a new cpu driver API function getModels() to retrieve the cpu models. The currect implementation to process the cpu_map XML content is transferred to the INTEL and PowerPC cpu driver specific API functions. Additionally processing the cpu_map XML file is not safe due to the fact that the cpu map does not exist for all architectures. Therefore it is better to encapsulate the processing in the architecture specific cpu drivers. Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 07 11月, 2014 3 次提交
-
-
由 Prerna Saxena 提交于
IBM Power processors differ uniquely across generations (such as power6, power7, power8). Each generation signifies a new PowerISA version that exhibits features unique to that generation. The higher 16 bits of PVR for IBM Power processors encode the CPU generation, while the CPU chip (sub)version is encoded in lower 16 bits. For all practical purposes of launching a VM, we care about the generation which the vCPU will belong to, and not specifically the chip version. This patch updates the libvirt PVR check to reflect this relationship. It allows libvirt to select the right CPU generation in case the exact match for a a specific CPU is not found. Hence, there will no longer be a need to add each PowerPC CPU model to cpu_map.xml; just adding entry for the matching ISA generation will suffice. It also contains changes to cpu_map.xml since processor generations as understood by QEMU compat mode go as "power6", "power7" or "power8" [Reference : QEMU commit 8dfa3a5e85 ] Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: NAnton Blanchard <anton@samba.org> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Prerna Saxena 提交于
PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea & 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7. This patch allows libvirt to exploit cpu mode 'host-model' to describe this new mode for PowerKVM guests. For example, when a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='host-model'> <model>power7</model> </cpu> Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com> Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com> Acked-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Prerna Saxena 提交于
This adds support for PowerPC Little Endian architecture., and allows libvirt to spawn VMs based on 'ppc64le' architecture. Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 29 10月, 2014 1 次提交
-
-
由 Eric Blake 提交于
C guarantees that static variables are zero-initialized. Some older compilers (and also gcc -fno-zero-initialized-in-bss) create larger binaries if you explicitly zero-initialize a static variable. * src/conf/nwfilter_conf.c: Fix initialization. * src/cpu/cpu_x86.c: Likewise. * src/interface/interface_backend_netcf.c: Likewise. * src/locking/lock_daemon.c: Likewise. * src/locking/lock_driver_lockd.c: Likewise. * src/locking/lock_driver_sanlock.c: Likewise. * src/network/bridge_driver.c: Likewise. * src/node_device/node_device_udev.c: Likewise. * src/nwfilter/nwfilter_learnipaddr.c: Likewise. * src/rpc/virnetserver.c: Likewise. * src/security/security_selinux.c (virSecuritySELinuxGenSecurityLabel): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 30 9月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
Commit de0aeafe filtered them out from the host-model features, to allow host-model to be migratable by default. Even though they are not passed to QEMU for host-passthrough, (and not enabled by default) filter them out too so the user does not think the domain has them. https://bugzilla.redhat.com/show_bug.cgi?id=1147584
-
- 18 9月, 2014 1 次提交
-