The capability was introduced in QEMU 1.3.1 and we require
QEMU 1.5.0 these days.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced by commit <af204232>.
Made redundant by commit 1e9a083 which switched to using
qemuProcessCreatePretendCmd, where capabilities are filtered
in qemuProcessInit after being fetched from the cache.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Commit 0bdb704 renamed the corresponding xml->argv tests,
but due to the optimistic nature of xml->startup xml testing,
this test was quietly skipped.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1613737
When processing the inputvol for encryption, we need to handle
the case where the inputvol is encrypted. This then allows for
the encrypted inputvol to be used either for an output encrypted
volume or an output volume of some XML provided type.
Add tests to show the various conversion options when either input
or output is encrypted. This includes when both are encrypted.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 39cef12a9 altered/fixed the inputvol processing to create
a multistep process when using an inputvol to create an encrypted
output volume; however, it unnecessarily assumed/restricted the
inputvol to be of 'raw' format only.
Modify the processing code to allow the inputvol format to be checked
and used in order to create the encrypted volume.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 39015a6f3 modified the test to be more reliable/realistic,
but without checking the return status of virEventRunDefaultImpl
it's possible that the test could run infinitely.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Previous commits removed all capabilities from per-device property
probing for:
pci-assign
kvm-pci-assign
usb-host
scsi-generic
Remove them from the virQEMUCapsDeviceProps list and get rid of the
redundant device-list-properties QMP calls.
Note that 'pci-assign' was already useless, because the QMP version
of the device is called 'kvm-pci-assign', see libvirt commit 7257480
from 2012.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Introduced by QEMU commit 28b77657 in v1.0-rc4~21^2~8.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Introduced by QEMU commit c29029d which was included in 1.5.0
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the bootindex argument was already supported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the configfd argument was already supported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Added by commit fc66c1603c and not used since.
Also, the device was present in QEMU 1.5.0 so this capability
will not be needed if we ever decide to implement usb-net support.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Attempting to use a chardev definition like
<serial type='unix'>
<target type='isa-serial'/>
</serial>
correctly results in an error being reported, since the source
path - a required piece of information - is missing; however,
the very similar
<serial type='unix'>
<target type='pci-serial'/>
</serial>
was happily accepted by libvirt, only to result in libvirtd
crashing as soon as the guest was started.
The issue was caused by checking the chardev's targetType
against whitelisted values from virDomainChrChannelTargetType
without first checking the chardev's deviceType to make sure
it is actually a channel, for which the check makes sense,
rather than a different type of chardev.
The only reason this wasn't spotted earlier is that the
whitelisted values just so happen to correspond to USB and
PCI serial devices and Xen and UML consoles respectively,
all of which are fairly uncommon.
https://bugzilla.redhat.com/show_bug.cgi?id=1609720
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
A few qemuxml2xml tests for virtio-input devices are
missing the capabilities used for the corresponding
qemuxml2argv tests: this wasn't a problem until now
because capabilities were only checked at command line
generation time, but we're going to change that later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1622455
If a domain is configured to use <source type='file'/> under
<memoryBacking/> we have to honour that setting and produce
-mem-path on the command line. We are not doing so if domain has
no guest NUMA nodes nor hugepages.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The new tests use DO_TEST_CAPS_ARCH_LATEST() with an input
XML describing a very simple headless guest and cover most
architectures and machine types we care about.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can add aarch64, ppc64 and riscv64 to the list of
supported architectures for the macro, since we have
capabilities data for all of them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-serial is an alias for virtio-serial-pci, which
should not have been used for a PCIe-less aarch64/virt
guest but it ended up being used anyway because the
virtio-mmio capability was missing and the algorithm
is buggy.
Fix the test case so that we can fix the algorithm next.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The current socket test is rather crazy in that it sets up a server
listening for sockets and then runs a client connect call, relying on
the fact that the kernel will accept this despite the application
not having called accept() yet. It then closes the client socket and
calls accept() on the server. On Linux accept() will always see that
the client has gone and so skip the rest of the code. On FreeBSD,
however, the accept sometimes succeeds, causing us to then go into
code that attempts to read and write to the client which will fail
aborting the test. The accept() never succeeds on FreeBSD guests
with a single CPU, but as you add more CPUs, accept() becomes more and
more likely to succeed, giving a 100% failure rate for the test when
using 8 CPUs.
This completely rewrites the test so that it is avoids this designed in
race condition. We simply spawn a background thread to act as the
client, which will read a byte from the server and write it back again.
The main thread can now properly listen and accept the client in a
synchronous manner avoiding any races.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The test code for UNIX and TCP sockets will need to be rewritten and
extended later, and will benefit from code sharing.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The expected output strings from the vshtabletest.c are created on a
modern Linux host where unicode printing support is very good. On older
Linux platforms, or non-Linux platforms, some unicode characters will
not be considered printable. While the vsh table alignment code will
stil do the right thing with escaping & aligning in this case, the
result will not match the test's expected output.
Since we know the code is working correctly, do a check with iswprint()
to validate the platform's quality and skip the test if it fails. This
fixes the test on FreeBSD platforms.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When switching the host architecture to something for which we do not
have any host CPU model defined, the mocked
virQEMUCapsProbeHostCPUForEmulator would just return the previous CPU
model resulting in strange combinations, such as "core2duo" host CPU
model in QEMU capabilities for "AArch64" architecture. It currently
doesn't break any test case, but we should fix it anyway to avoid future
surprises which would be quite hard to debug.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Test that we correctly accept 64-bit unsigned numbers for QEMU.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We expect to get numbers as big as ULLONG_MAX from QEMU,
add a test for them.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of printing the whole JSON in error messages,
print just the test name.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This test gets its JSON docs from files.
Now that we have a 'name' field in testInfo, use it instead
of abusing the 'doc' field.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Give the testing function access to the test name instead of only
passing it to virTestRun.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit 6534b3c4 tried to raise an error when there is no numa
nodes by setting access='shared' in the domain config, but added
a helper called from qemuDomainDeviceDefValidate instead of a
helper called from qemuDomainDefValidate for XML:
<memoryBacking>
<hugepages/>
<access mode='shared'/>
</memoryBacking>
Since there are no memory devices in the test XML, there would
be no validation failure, but the test added was still failing.
Investigating that it turns out that unnecessary XML elements
were causing the failure (no need for <video>, <graphics>,
<pm>, usb controller model "piix3-uhci", disk attribute for
"discard='unmap'", <serial>, <console>, <channel> and a
memballoon model). Removing all those before moving the method
caused the test to succeed.
So this patch moves the validation to the right place and
removes all the unnecessary XML pieces that were causing
a false validation failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1448149#c14
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The reason of broken build was that centos and rhel use older version of
glibc. These versions of glibc on these platforms cannot work with newer
unicodes, thus causing functions iswprint() and wcwidth() return
unexpected values causing the vshtabletest to fail. Therefore, let's
replace the new unicode characters causing issues with some older ones
to fix the test suite, as the issue would still persist during runtime.
Signed-off-by: Simon Kobyda <skobyda@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
None of the existing models is suitable for use with
RISC-V virt guests, and we don't want information about
the serial console to be missing from the XML.
The name is based on comments in qemu/hw/riscv/virt.c:
RISC-V machine with 16550a UART and VirtIO MMIO
and in qemu/hw/char/serial.c:
QEMU 16550A UART emulation
along with the output of dmesg in the guest:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
base_baud= 230400) is a 16550A
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The architecture is new enough that we don't need to
concern ourselves with backwards compatibility in any
capacity.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the generated testcase to test the generated command against the
QMP schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Many of the parameters are omitted for NULL/0 situations. Change the
values for these cases so all the arguments are schema-checked.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Historically the argv -> xml convertor wanted the same default machine
as we'd set when parsing xml. The latter has now changed, however, to
use a default defined by libvirt. The former needs fixing to again
honour the default QEMU machine.
This exposed a bug in handling for the aarch64 target, as QEMU does not
define any default machine. Thus we should not having been accepting
argv without a -machine provided.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default
machine any more, instead it gets the historical default that libvirt
prefers for each arch. Rename it, so that the old name can be used for
getting QEMU's default.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We don't honour the QEMU default machine type anymore, always using the
libvirt chosen default instead. The QEMU argv parser, however, will need
to know the exacty QEMU default, so we must record that info.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
'metadata' and 'leases' are features internal to libvirt and thus don't
influence the generated QEMU command line. As they are not tested we
don't need the output files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Now we assume the flag always so there's no use for this test. Probably
a leftover from the cleanup of the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The test files were unused, but we don't have any other test for this
feature. Make use of the existing files by removing disks and using
DO_TEST_CAPS_LATEST to execute them. The legacy output files will be
dropped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
aarch64-acpi-nouefi and hostdev-scsi-boot are unused. Noticed when
checking whether '-nodefconfig' is still used by libvirt.
Unused since their introduction in commit deb38c4 and bab6ee6
respectively.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability was usable since qemu 1.3 so we can remove all the
detection code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
All supported qemus support FD passing so modify the tests to test the
proper code path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
For versions where we can probe that the arguments are optional we can
perform the probing by a schema query rather than sending a separate
command to do so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
For now, there are 9 test cases
- testVshTableNew: Creating table with empty header
- testVshTableHeader: Printing table with/without header
- testVshTableRowAppend: Appending row with various number of cells.
Only row with same number of cells as in header is accepted.
- testUnicode: Printing table with unicode characters.
Checking correct alignment.
- testUnicodeArabic: test opposite (right to left) writing
- testUnicodeZeroWidthChar
- testUnicodeCombiningChar
- testUnicodeNonPrintableChar,
- testNTables: Create and print varios types of tables - one column,
one row table, table without content, standart table...
Signed-off-by: Simon Kobyda <skobyda@redhat.com>
Instead of printing it straight in virsh, it creates table struct
which is filled with header and rows(domains). It allows us to know
more about table before printing to calculate alignment right.
Signed-off-by: Simon Kobyda <skobyda@redhat.com>
With blockdev we can use the full range of commands to manipulate the
tray and the medium separately. Implement monitor code for this.
Schema testing done in the qemumonitorjsontest allows us to verify that
we generate the commands correctly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The copy-on-read feature is expressed by adding a new node layer in
qemu when using -blockdev. Since we will keep these per-disk (as opposed
to per storage source) we need to store the appropriate node names in
the disk definition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When using -blockdev you need to use the qom path to refer to the disk
fronends. Add means for storing the path and getting it after restart.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to backing store indexes which will become stable eventually
we need also to be able to format and store in the status XML for later
use the index for the top level of the backing chain.
Add XML formatter, parser, schema and docs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Node names for block objects in qemu need to be unique for an instance
of the qemu process. Add a counter to generate objects sequentially and
store it in the status XML so that we can restore it.
The helpers added allow to create new node names and reset the counter
after the VM process terminates.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If a user configures the backing chain in the XML we should not ignore
it. We already do parse it but don't format it out. As a
safety-precaution don't attempt to format detected chain into the
inactive XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add test data for nested backing chains with/without indexes (used in
status XMLs) which will excercise blockdev and the related work.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The blockdev support will change existing approach to add disks to VMs
so all tests using the DO_TEST_CAPS_LATEST approach which have any disks
need to be forked so that the changes can be applied.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'device' field reported by 'query-block' is empty when -blockdev is
used. Add an argument which will allow matching disk by using the qdev
id so we can use this code with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'device' argument matches only the legacy drive alias. For blockdev
we need to set the throttling for a QOM id and thus we'll need to use
the 'id' field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use qemuDomainAttachDeviceDiskLive to change the media in
qemuDomainChangeDiskLive as the former function already does all the
necessary steps to prepare the new medium.
This also allows us to turn qemuDomainChangeEjectableMedia static.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We don't use it for anything useful so it does not make much sense to
extract it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Print the differences in case when the expected data does not match.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since we're not saving the platform-specific data into a cache, we're
not going to populate the structure, which in turn will cause a crash
upon calling virNodeGetSEVInfo because of a NULL pointer dereference.
Ultimately, we should start caching this data along with host-specific
capabilities like NUMA and SELinux stuff into a separate cache, but for
the time being, this is a semi-proper fix for a potential crash.
Backtrace (requires libvirtd restart to load qemu caps from cache):
#0 qemuGetSEVInfoToParams
#1 qemuNodeGetSEVInfo
#2 virNodeGetSEVInfo
#3 remoteDispatchNodeGetSevInfo
#4 remoteDispatchNodeGetSevInfoHelper
#5 virNetServerProgramDispatchCall
#6 virNetServerProgramDispatch
#7 virNetServerProcessMsg
#8 virNetServerHandleJob
#9 virThreadPoolWorker
#10 virThreadHelper
https: //bugzilla.redhat.com/show_bug.cgi?id=1612009
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
So the procedure to detect SEV support works like this:
1) we detect that sev-guest is among the QOM types and set the cap flag
2) we probe the monitor for SEV support
- this is tricky, because QEMU with compiled SEV support will always
report -object sev-guest and query-sev-capabilities command, that
however doesn't mean SEV is supported
3) depending on what the monitor returned, we either keep or clear the
capability flag for SEV
Commit a349c6c21c added an explicit check for "GenericError" in the
monitor reply to prevent libvirtd to spam logs about missing
'query-sev-capabilities' command. At the same time though, it returned
success in this case which means that we didn't clear the capability
flag afterwards and happily formatted SEV into qemuCaps. Therefore,
adjust all the relevant callers to handle -1 on errors, 0 on SEV being
unsupported and 1 on SEV being supported.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
In order to test SEV we need real QEMU capabilities. Ideally, this would
be tested with -latest capabilities, however, our capabilities are
currently tied to Intel HW, even the 2.12.0 containing SEV were edited by
hand, so we can only use that one for now, as splitting the capabilities
according to the vendor is a refactor for another day. The need for real
capabilities comes from the extended SEV platform data (PDH, cbitpos,
etc.) we'll need to cache/parse.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@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>
As advertised in the previous commit, we need the list of
accessed files to also contain action that caused the $path to
appear on the list. Not only this enables us to fine tune our
white list rules it also helps us to see why $path is reported.
For instance:
/run/user/1000/libvirt/libvirt-sock: connect: qemuxml2argvtest: QEMU XML-2-ARGV net-vhostuser-multiq
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The check-file-access.pl script is used to match access list
generated by virtestmock against whitelisted rules stored in
file_access_whitelist.txt. So far the rules are in form:
$path: $progname: $testname
This is not sufficient because the rule does not take into
account 'action' that caused $path to appear in the list of
accessed files. After this commit the rule can be in new form:
$path: $action: $progname: $testname
where $action is one from ("open", "fopen", "access", "stat",
"lstat", "connect"). This way the white list can be fine tuned to
allow say access() but not connect().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
So far we are setting only fake secret and storage drivers.
Therefore if the code wants to call a public NWFilter API (like
qemuBuildInterfaceCommandLine() and qemuBuildNetCommandLine() are
doing) the virGetConnectNWFilter() function will try to actually
spawn session daemon because there's no connection object set to
handle NWFilter driver.
Even though I haven't experienced the same problem with the rest
of the drivers (interface, network and node dev), the reasoning
above can be applied to them as well.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This proves libvirt can now handle high socket_id and
core_id values correctly and ensures we won't introduce
regressions in this area.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The latter are no longer used by libvirt, and the former
never were; moreover, both have a corresponding *_list
file which we can manipulate very conveniently using our
bitmap APIs, so dropping them makes sure in the future
developers will look into that rather than trying to
parse the kernel binary bitmaps.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Some of the data dumps didn't include them; luckily,
we're not actually missing any information since we
can recreate them by looking at the corresponding
thread_sibilings files.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Add new XML section to report host's memory bandwidth allocation
capability. The format as below example:
<host>
.....
<memory_bandwidth>
<node id='0' cpus='0-19'>
<control granularity='10' min ='10' maxAllocs='8'/>
</node>
</memory_bandwidth>
</host>
granularity ---- granularity of memory bandwidth, unit percentage.
min ---- minimum memory bandwidth allowed, unit percentage.
maxAllocs ---- maximum memory bandwidth allocation group supported.
Signed-off-by: Bing Niu <bing.niu@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Introduce a new section memorytune to support memory bandwidth allocation.
This is consistent with existing cachetune. As the example:
below:
<cputune>
......
<memorytune vcpus='0'>
<node id='0' bandwidth='30'/>
</memorytune>
</cputune>
vpus --- vpus subjected to this memory bandwidth.
id --- on which node memory bandwidth to be set.
bandwidth --- the memory bandwidth percent to set.
Signed-off-by: Bing Niu <bing.niu@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If a domain has hugepages configured and we're currently building
memory-backend-file for a nvdimm device that domain has we will
put hugepages path onto the command line. It should have been
nvdimm path configured in the XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This reverts commit 9cf38263d0.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 4dd6054000.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit c31146685f.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit 397447f805.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Previously we were ignoring "nodeset" attribute for hugepage pages
if there was no guest NUMA topology configured in the domain XML.
Commit <fa6bdf6afa878b8d7c5ed71664ee72be8967cdc5> partially fixed
that issue but it introduced a somehow valid regression.
In case that there is no guest NUMA topology configured and the
"nodeset" attribute is set to "0" it was accepted and was working
properly even though it was not completely valid XML.
This patch introduces a workaround that it will ignore the nodeset="0"
only in case that there is no guest NUMA topology in order not to
hit the validation error.
After this commit the following XML configuration is valid:
<memoryBacking>
<hugepages>
<page size='2048' unit='KiB' nodeset='0'/>
</hugepages>
</memoryBacking>
but this configuration remains invalid:
<memoryBacking>
<hugepages>
<page size='2048' unit='KiB' nodeset='0'/>
<page size='1048576' unit='KiB'/>
</hugepages>
</memoryBacking>
The issue with the second configuration is that it was originally
working, however changing the order of the <page> elements resolved
into using different page size for the guest. The code is written
in a way that it expect only one page configured and always uses only
the first page in case that there is no guest NUMA topology configured.
See qemuBuildMemPathStr() function for details.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1591235
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We can safely validate the hugepage nodeset attribute at a define time.
This validation is not done for already existing domains when the daemon
is restarted.
All the changes to the tests are necessary because we move the error
from domain start into XML parse.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This use-case was broken by commit
<fa6bdf6afa878b8d7c5ed71664ee72be8967cdc5>.
We allowed this configuration and it was working as expected therefore
we can consider it as regression. We should have never allowed such
configuration so now the best solution is in case of non-numa guest
silently ignore the 'nodeset' attribute if it's set to '0'.
That will be fixed by following patches.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This test case is currently working but it uncovers existing issue
in our code that the generated QEMU commandline uses the default 1G
hugepage instead of the 2M hugepage specified for exact node.
The issue in our code is that for non-numa guests we take into account
only the first hugepage. This will be fixed as invalid configuration
since it doesn't make any sense to set default and specific hugepage
for non-numa guest.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
