IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Allow to define NUMA nodes without memory or CPUs assigned to properly
support the new acpi-generic-initiator device.
This is required because the NUMA nodes passed to the
acpi-generic-initiator object must be independent and not be shared with
other resources, such as CPU or memory.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Andrea Righi <arighi@nvidia.com>
This capability tracks whether QEMU supports the acpi-generic-initiator
object type.
This object has been introduced in QEMU with the commit:
b64b7ed8bb ("qom: new object to associate device to NUMA node").
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Andrea Righi <arighi@nvidia.com>
The include header got its type checks fixed in curl 8.14:
79b4e56b3fhttps://github.com/curl/curl/pull/17143
This causes a warning on rawhide with clang:
../src/esx/esx_vi.c:318:5: error: call to '_curl_easy_setopt_err_long'
declared with 'warning' attribute: curl_easy_setopt expects a long
argument [-Werror,-Wattribute-warning]
318 | curl_easy_setopt(curl->handle, CURLOPT_NOSIGNAL, 1);
| ^
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
With qom-list-get we already have the value of unavailable-features
property in the returned object (just like we have all values of all
bool properties). Let's use the value from there instead of querying for
it separately using qom-get.
After this patch only a single QMP command is used for getting all the
required info about guest CPUs created by QEMU 10.1 or newer.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuMonitorJSONGetCPUDataDisabled function is just a wrapper around
two function calls and it is only used by qemuMonitorJSONGetGuestCPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuMonitorJSONGetCPUData function is just a wrapper around two
function calls and it is only used by qemuMonitorJSONGetGuestCPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function translates a list of CPU feature names retrieved from QEMU
and adds them to virCPUData.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test cases show both the legacy method and the new one produce
identical results.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qom-list-get is a new QMP command (since QEMU 10.1) that combines
qom-list for listing properties of a specified object with qom-get for
getting a value of a given property. The new command provides an array
of all properties and their values, which allows us to dramatically
reduce the number of QMP commands we have to call when starting a domain
to check which CPU features were actually enabled.
A simple domain with no disk can now be started with only 15 QMP
commands in about 200 ms compared to 485 commands and 400 ms startup
time without this patch.
https://issues.redhat.com/browse/RHEL-7038
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuMonitorJSONParsePropsList API expected a QMP reply as an input.
By generalizing it to work on any JSON array, we can reuse the API even
for commands which return the array of properties nested in an object.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When getting enabled CPU features (qemuMonitorJSONGetCPUData), we used
to call qemuMonitorJSONGetCPUProperties to get the list of all boolean
properties and then queried their values and ignored properties that
were not true. By moving the filtering inside
qemuMonitorJSONGetCPUProperties we don't need to even add disabled
features to any list and also get ready for better QMP interface.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuMonitorJSONParsePropsList supported filtering based on type. Let's
replace it with a callback supplied by the caller to allow for more
advanced filtering.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The key point here is that the unavailable-features property reports an
empty array.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The SierraForest CPU was just randomly chosen and it doesn't mean we
should have test cases for all CPU models.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The legacy probing which reads CPUID registers from QEMU and interprets
the individual bits is not used with any QEMU version currently
supported by libvirt. The code would only be used if
QEMU_CAPS_CPU_UNAVAILABLE_FEATURES capability (detected by probing the
presence of 'unavailable-features') was missing on x86, but all QEMU
release we care about report unavailable-features on x86.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
clarify that "guest" time is time spent running VCPUs specifically.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Add documentation on the way libvirt displays the Host CPU
model and capabilities (features). There is an implicit
expectation from users to get the CPU model name matching the
CPU model they are running on, however, this does not happen
most of the time. As a consequence, having a documentation
is useful both for users to align their expectation and for
us to point to a place where the situation is clearly explained.
Signed-off-by: Hector Cao <hector.cao@canonical.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This is useful for checking that the script still covers everything when
using it to compare two .replies files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While 'query-command-line-options' is usually fairly stable (for
comparing between two .replies files) it's simpler to compare it in the
dumped variant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Process few other simple commands. While this output doesn't change
places it's useful to see it when comparing the dumps of two .replies
files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The --dump-* mode can be used together with --repliesdir which iterates
over all '.replies' files in the directory. Make this useful by
outputing the filename so the user can associate the data with the file
it was dumped from.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to 'device-list-properties' libvirt probes also some
properties of qom types. Since the format is identical make the dumping
function for 'device-list-properties' universal and make it accept also
'qom-list-types'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Dumps the supported machine types and their deprecation state in stable
human-sort order.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While '--dump-qmp-query-strings' is useful by itself because it's a
simple way to generate the QMP schema query strings for libvirt, the
other modes aren't useful besides comparing two .replies files by the
dumped output.
Remove specific options for '--dump-qom-list-types' and
'--dump-device-list-properties', so that upcoming additions which will
be useful only for comparisons aren't forced to add these options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently the conversation was a list of tuples. Since upcoming patches
will want to store some additional flags with the processed commands
convert it to a list of dicts, so that we can name the individual
fields.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the qemu capabilities dump for the qemu-10.2 cycle was added
and thus qemu-10.1 dump is no longer "latest" we can pin the
'cpu-host-' tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is an extremely early addition with data as of v10.1.0-1-ge771ba98de
thus effectively no code change compared to the qemu-10.1 release.
This early addition is done since I've upgraded the computer I'm
capturing the dumps from (yes the dumps are host-specific, and there
isn't really a good option if we want to have modern CPU data around).
Thus the only difference in the output files comes from the CPU change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu-10.2 which we're about to add capabilities dump for will remove the
'4.2' machine type per deprecation policy.
The 'x86_64-default-cpu-*' still reference it. Since there is no
functional difference when upgrading the tests to the latest machine
type (pc/q35 alias as handled internally by qemuxmlconftest) let's
rename and modernize these.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
