The function now works on virCPUx86DataItem and it's renamed as
virCPUx86DataItemAndBits.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The parameters changed from virCPUx86CPUID to virCPUx86DataItem and the
function is now called virCPUx86DataItemClearBits.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is renamed as virCPUx86DataItemSetBits and it works on
virCPUx86DataItem now.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virCPUx86DataSorter already compares two virCPUx86DataItem structs.
Let's add a tiny wrapper around it called virCPUx86DataCmp and use it
instead of open coded comparisons.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It is called virCPUx86DataSorter since the function will work on any CPU
data type.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is now called virCPUx86DataNext to reflect its purpose: it
is an iterator over CPU data (both CPUID and MSR in the near future).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Although vendor string is always reported by CPUID, the container struct
is used for consistency and thus "cpuid" name is not a good fit anymore.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The following patches introduce CPU features read from MSR in addition
to those queried via CPUID instruction. Let's introduce a container
struct which will be able to describe either feature type.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Vim has trouble figuring out the filetype automatically because
the name doesn't follow existing conventions; annotations like
the ones we already have in Makefile.ci help it out.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A feature with no cpuid element is invalid and it should not be silently
treated as a feature with all CPUID bits set to zero.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The microcode version checks are used to invalidate cached CPU data we
get from QEMU. To minimize /proc/cpuinfo parsing the microcode version
was only read when libvirtd started and cached for the daemon's
lifetime. However, the CPU microcode can change anytime (updating the
microcode package can automatically upload it to the CPU) and we need to
stop caching it to avoid using stale CPU model data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to the official documentation for autoconf[1], the
correct names for these variables are abs_top_{src,build}dir
rather than abs_top{src,build}dir; in fact, we're already
using the correct names in various places, so let's just make
everything nice and consistent.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Problem is that if there are no signatures for a CPU, then we
still allocate cpu->signatures (even though with size 0). Later,
we access cpu->signatures[0] if cpu->signatures is not NULL.
Invalid read of size 4
at 0x5F439D7: virCPUx86Translate (cpu_x86.c:2930)
by 0x5F3C239: virCPUTranslate (cpu.c:927)
by 0x57CE7A1: qemuProcessUpdateGuestCPU (qemu_process.c:5870)
...
Address 0xf752d40 is 0 bytes after a block of size 0 alloc'd
at 0x4C30EC6: calloc (vg_replace_malloc.c:711)
by 0x5DBDE4E: virAllocN (viralloc.c:190)
by 0x5F3E4FA: x86ModelCopySignatures (cpu_x86.c:990)
by 0x5F3E60F: x86ModelCopy (cpu_x86.c:1008)
by 0x5F3E7CB: x86ModelFromCPU (cpu_x86.c:1068)
by 0x5F4397E: virCPUx86Translate (cpu_x86.c:2922)
by 0x5F3C239: virCPUTranslate (cpu.c:927)
by 0x57CE7A1: qemuProcessUpdateGuestCPU (qemu_process.c:5870)
...
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The function exports the functionality of x86DataToSignatureFull and
x86MakeSignature to the test suite.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The log message may be useful when debugging why a specific CPU model
was selected for a given set of CPUID data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
CPU signatures in the cpu_map serve as a hint for CPUID to CPU model
matching algorithm. If the CPU signatures matches any CPU model in the
cpu_map, this model will be the preferred one.
This works out well and solved several mismatches, but in real world
CPUs which should match a single CPU model may be produced with several
different signatures. For example, low voltage Broadwell CPUs for
laptops and Broadwell CPUs for servers differ in CPU model numbers while
we should detect them all as Broadwell CPU model.
This patch adds support for storing several signatures for a single CPU
model to make this hint useful for more CPUs. Later commits will provide
additional signatures for existing CPU models, which will correct some
results in our CPU test suite.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In preparation for storing several CPU signatures in a single CPU model,
we need to turn virCPUx86Model's signature into an array of signatures.
The parser still hardcodes the number of signatures to 1, but the
following patch will drop this limit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a helper for copying CPU signature between two CPU models.
It's not very useful until the way we store signatures is changed in the
next patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Having multiple CPU model definitions with the same name could result in
unexpected behavior.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code is separated into a new x86ModelParseFeatures function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code is separated into a new x86ModelParseVendor function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code is separated into a new x86ModelParseSignature function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code is separated into a new x86ModelParseAncestor function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Require that all headers are guarded by a symbol named
LIBVIRT_$FILENAME
where $FILENAME is the uppercased filename, with all characters
outside a-z changed into '_'.
Note we do not use a leading __ because that is technically a
namespace reserved for the toolchain.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In many files there are header comments that contain an Author:
statement, supposedly reflecting who originally wrote the code.
In a large collaborative project like libvirt, any non-trivial
file will have been modified by a large number of different
contributors. IOW, the Author: comments are quickly out of date,
omitting people who have made significant contribitions.
In some places Author: lines have been added despite the person
merely being responsible for creating the file by moving existing
code out of another file. IOW, the Author: lines give an incorrect
record of authorship.
With this all in mind, the comments are useless as a means to identify
who to talk to about code in a particular file. Contributors will always
be better off using 'git log' and 'git blame' if they need to find the
author of a particular bit of code.
This commit thus deletes all Author: comments from the source and adds
a rule to prevent them reappearing.
The Copyright headers are similarly misleading and inaccurate, however,
we cannot delete these as they have legal meaning, despite being largely
inaccurate. In addition only the copyright holder is permitted to change
their respective copyright statement.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Support Hyper-V Enlightened VMCS in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_EVMCS
cases to src/qemu/* for now.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Support Hyper-V PV IPI enlightenment in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI
cases to src/qemu/* for now.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
All of the ones being removed are pulled in by internal.h. The only
exception is sanlock which expects the application to include <stdint.h>
before sanlock's headers, because sanlock prototypes use fixed width
int, but they don't include stdint.h themselves, so we have to leave
that one in place.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
In preparation for splitting up the CPU map data file, move it into a
dedicated directory of its own.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Get rid of the separate 'error:' label, so all code paths jump straight
to the 'cleanup:' label.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The x86 and ppc impls both duplicate some logic when parsing CPU
features. Change the callback signature so that this duplication can be
pushed up a level to common code.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Two pieces of code accidentally jumped to the wrong label when they
failed causing incorrect cleanup, returning a partially initialized
CPU model struct.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Allow for syntax
<include filename="subdir/fooo.xml"/>
to reference other files in the CPU database directory
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Qemu-3.0 supports Hyper-V-style PV TLB flush, Windows guests can benefit
from this feature as KVM knows which vCPUs are not currently scheduled (and
thus don't require any immediate action).
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Qemu-3.0 supports so-called 'Reenlightenment' notifications and this (in
conjunction with 'hv-frequencies') can be used make Hyper-V on KVM pass
stable TSC page clocksource to L2 guests.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Qemu-2.12 gained 'hv-frequencies' cpu flag to enable Hyper-V frequency
MSRs. These MSRs are required (but not sufficient) to make Hyper-V on
KVM pass stable TSC page clocksource to L2 guests.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
AMD x86 CPUs have two separate ways to mitigate the Speculative Store
Bypass hardware flaw. In current processors only non-architectural MSRs
are available, and so hypervisors must expose a virtualized MSR and CPU
flag "virt-ssbd" (CPUID Function 8000_0008, EBX[25]=1).
In future processors AMD will provide an architectural MSR, indicated by
existance of the CPUID Function 8000_0008, EBX[24]=1, to which QEMU has
given the name "amd-ssbd".
The "amd-ssbd" flag should be used in preference to "virt-ssbd", if it
is available, since it provides improved performance. For virtual
machine configuration, both should be exposed when available, to allow
for maximal guest OS compatibility as not all guests yet support both.
If future processes are not vulnerable to the flaw, this will be
indicated by the existance of CPUID Function 8000_0008, EBX[26]=1,
to which QEMU has given the name "amd-no-ssb".
See also 124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
from:
https://bugzilla.kernel.org/show_bug.cgi?id=199889
Note that neither amd-ssbd or amd-no-ssb will be reported by the kernel
in /proc/cpuinfo. It knows about these CPUID bits and does the right thing,
but doesn't report their existance as distinct flags in /proc/cpuinfo.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When computing a baseline CPU for a specific hypervisor we have to make
sure to include only CPU features supported by the hypervisor. Otherwise
the computed CPU could not be used for starting a new domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
To make it more consistent with the rest of the CPU driver code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
This is required for virCPUBaseline to accept a list of guest CPU
definitions since they do not have arch set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Modern host CPU models from domain capabilities XMLs are reported as
guest CPU definitions with feature policies. This patch updates
virCPUx86Baseline to properly handle such CPU models.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
