Erik Skultety [Thu, 25 Jan 2018 15:13:37 +0000 (16:13 +0100)]
vsh: Cmd aliases lookups should return results for the aliased command
Unfortunately, we have a number of aliases in virsh and even though
these are not visible any more, we have to support them. The problem is
that when trying to print help for the alias, we get SIGSEGV because
there isn't any @def structure anymore and we need to query the command
being aliased instead.
Erik Skultety [Thu, 25 Jan 2018 15:08:46 +0000 (16:08 +0100)]
vsh: Drop redundant definition searches from vshCmd{def,Grp}Help
These helpers are called from a single place only - cmdHelp wrapper and
just before the wrapper invokes the helpers, it performs the search,
either for command group or for the command itself, except the result is
discarded and the helper therefore needs to do it again. Drop this
inefficient handling and pass the @def structure rather than a name,
thus preventing the helper from needing to perform the search again.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
qemu: add support for generating SMBIOS OEM strings command line
This wires up the previously added OEM strings XML schema to be able to
generate comamnd line args for QEMU. This requires QEMU >= 2.12 release
containing this patch:
conf: add support for setting OEM strings SMBIOS data fields
The OEM strings table in SMBIOS allows the vendor to pass arbitrary
strings into the guest OS. This can be used as a way to pass data to an
application like cloud-init, or potentially as an alternative to the
kernel command line for OS installers where you can't modify the install
ISO image to change the kernel args.
As an example, consider if cloud-init and anaconda supported OEM strings
you could use something like
use of a application specific prefix as illustrated above is
recommended, but not mandated, so that an app can reliably identify
which of the many OEM strings are targetted at it.
Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Introduce initial support for domainBlockStats API
the libxl driver calls a couple of xenstore APIs, so it must explicitly
link to this library rather than rely on indirect linkage via libxl or
other xen libraries.
Reviewed-by: Jim Fehlig <jfehlig@suse.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Michal Koutný [Wed, 10 Jan 2018 22:06:41 +0000 (23:06 +0100)]
libvirtd: Explicit dependency on systemd-machined
The libvirtd daemon uses systemd-machined D-Bus API when manipulating
domains. The systemd-machined is D-Bus activated on demand.
However, during system shutdown systemd-machined is stopped concurrently
with libvirtd and virsh users also doing their final cleanup may
transitively fail due to unavailability of systemd-machined. Example
error message
To circumvent this we need to explicitly specify both ordering and
requirement dependency (to avoid late D-Bus activation) on
systemd-machined. See [1] for the dependency debate.
Laine Stump [Wed, 17 Jan 2018 21:47:06 +0000 (16:47 -0500)]
qemu: auto-add generic xhci rather than NEC xhci to Q35 domains
We recently added a generic XHCI USB3 controller to QEMU, and libvirt
supports adding that controller rather than the NEC XHCI USB3
controller, but when auto-adding a USB controller to Q35 domains we
were still adding the vendor-specific NEC controller. This patch
changes to add the generic controller instead, if it's available in
the QEMU binary that will be used.
Signed-off-by: Laine Stump <laine@laine.org> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 22 Jan 2018 10:37:04 +0000 (11:37 +0100)]
qemu: Refresh caps cache after booting a different kernel
Whenever a different kernel is booted, some capabilities related to KVM
(such as CPUID bits) may change. We need to refresh the cache to see the
changes.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Laine Stump [Mon, 18 Dec 2017 15:19:40 +0000 (10:19 -0500)]
qemu: move qemuDomainDefValidateVideo into qemuDomainDeviceDefValidateVideo
qemuDomainDefValidateVideo() (called from qemuDomainDefValidate()) is
just a loop performing various checks on each video device. Rather
than maintaining this separate function, just fold the validations
into qemuDomainDeviceDefValidateVideo(), which is called once for each
video device.
Laine Stump [Fri, 15 Dec 2017 16:42:35 +0000 (11:42 -0500)]
qemu: assign correct type of PCI address for vhost-scsi when using pcie-root
Commit 10c73bf1 fixed a bug that I had introduced back in commit 70249927 - if a vhost-scsi device had no manually assigned PCI
address, one wouldn't be assigned automatically. There was a slight
problem with the logic of the fix though - in the case of domains with
pcie-root (e.g. those with a q35 machinetype),
qemuDomainDeviceCalculatePCIConnectFlags() will attempt to determine
if the host-side PCI device is Express or legacy by examining sysfs
based on the host-side PCI address stored in
hostdev->source.subsys.u.pci.addr, but that part of the union is only
valid for PCI hostdevs, *not* for SCSI hostdevs. So we end up trying
to read sysfs for some probably-non-existent device, which fails, and
the function virPCIDeviceIsPCIExpress() returns failure (-1).
By coincidence, the return value is being examined as a boolean, and
since -1 is true, we still end up assigning the vhost-scsi device to
an Express slot, but that is just by chance (and could fail in the
case that the gibberish in the "hostside PCI address" was the address
of a real device that happened to be legacy PCI).
Since (according to Paolo Bonzini) vhost-scsi devices appear just like
virtio-scsi devices in the guest, they should follow the same rules as
virtio devices when deciding whether they should be placed in an
Express or a legacy slot. That's accomplished in this patch by
returning early with virtioFlags, rather than erroneously using
hostdev->source.subsys.u.pci.addr. It also adds a test case for PCIe
to assure it doesn't get broken in the future.
Jim Fehlig [Sat, 6 Jan 2018 00:10:47 +0000 (17:10 -0700)]
nodedev: Fix failing to parse PCI address for non-PCI network devices
Commit 8708ca01c added virNetDevSwitchdevFeature() to check if a network
device has Switchdev capabilities. virNetDevSwitchdevFeature() attempts
to retrieve the PCI device associated with the network device, ignoring
non-PCI devices. It does so via the following call chain
For non-PCI network devices (qeth, Xen vif, etc),
virPCIGetDeviceAddressFromSysfsLink() will report an error when
virPCIDeviceAddressParse() fails. virPCIDeviceAddressParse() also
logs an error. After commit 8708ca01c there are now two errors reported
for each non-PCI network device even though the errors are harmless.
To avoid the errors, introduce virNetDevIsPCIDevice() and use it in
virNetDevGetPCIDevice() before attempting to retrieve the associated
PCI device. virNetDevIsPCIDevice() uses the 'subsystem' property of the
device to determine if it is PCI. See the sysfs rules in kernel
documentation for more details
Problem is that we need mon->lastError to be set because it's
used all over the place. Also, there's nothing wrong with
reporting error if one occurred. I mean, if there's a thread
executing an API and which currently is talking on monitor it
definitely wants the error reported.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Ján Tomko [Thu, 18 Jan 2018 09:14:41 +0000 (10:14 +0100)]
Raise the frame limit for tests
After the latest CPU additions, the build fails with clang:
cputest.c:905:1: error: stack frame size of 26136 bytes
in function 'mymain' [-Werror,-Wframe-larger-than=]
qemu: avoid denial of service reading from QEMU monitor (CVE-2018-5748)
We read from QEMU until seeing a \r\n pair to indicate a completed reply
or event. To avoid memory denial-of-service though, we must have a size
limit on amount of data we buffer. 10 MB is large enough that it ought
to cope with normal QEMU replies, and small enough that we're not
consuming unreasonable mem.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Andrea Bolognani [Wed, 17 Jan 2018 15:57:49 +0000 (16:57 +0100)]
news: Update for 4.0.0
As usual, a bunch of changes slipped through the cracks during the
development cycle. Update the release notes to include at least the
most notable ones.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Jiri Denemark [Tue, 9 Jan 2018 20:47:29 +0000 (21:47 +0100)]
cpu: Add Skylake-Server-IBRS CPU model
This is a variant of Skylake-Server with indirect branch prediction
protection. The only difference between Skylake-Server and
Skylake-Server-IBRS is the added "spec-ctrl" feature.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Tue, 9 Jan 2018 20:41:31 +0000 (21:41 +0100)]
cpu: Add Skylake-Client-IBRS CPU model
This is a variant of Skylake-Client with indirect branch prediction
protection. The only difference between Skylake-Client and
Skylake-Client-IBRS is the added "spec-ctrl" feature.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Tue, 9 Jan 2018 20:36:28 +0000 (21:36 +0100)]
cpu: Add Broadwell-IBRS CPU model
This is a variant of Broadwell with indirect branch prediction
protection. The only difference between Broadwell and Broadwell-IBRS is
the added "spec-ctrl" feature.
The Broadwell-IBRS model in QEMU is a bit different since Broadwell got
several additional features since we added it in cpu_map.xml:
abm, arat, f16c, rdrand, vme, xsaveopt
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 8 Jan 2018 19:53:25 +0000 (20:53 +0100)]
cpu: Add Broadwell-noTSX-IBRS CPU model
This is a variant of Broadwell-noTSX with indirect branch prediction
protection. The only difference between Broadwell-noTSX and
Broadwell-noTSX-IBRS is the added "spec-ctrl" feature.
The Broadwell-noTSX-IBRS model in QEMU is a bit different since
Broadwell-noTSX got several additional features since we added it in
cpu_map.xml:
abm, arat, f16c, rdrand, vme, xsaveopt
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 8 Jan 2018 19:53:25 +0000 (20:53 +0100)]
cpu: Add Haswell-IBRS CPU model
This is a variant of Haswell with indirect branch prediction protection.
The only difference between Haswell and Haswell-IBRS is the added
"spec-ctrl" feature.
The Haswell-IBRS model in QEMU is a bit different since Haswell got
several additional features since we added it in cpu_map.xml:
arat, abm, f16c, rdrand, vme, xsaveopt
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Tue, 9 Jan 2018 19:40:03 +0000 (20:40 +0100)]
cpu: Add Haswell-noTSX-IBRS CPU model
This is a variant of Haswell-noTSX with indirect branch prediction
protection. The only difference between Haswell-noTSX and
Haswell-noTSX-IBRS is the added "spec-ctrl" feature.
The Haswell-noTSX-IBRS model in QEMU is a bit different since
Haswell-noTSX got several additional features since we added it in
cpu_map.xml:
arat, abm, f16c, rdrand, vme, xsaveopt
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 8 Jan 2018 19:53:25 +0000 (20:53 +0100)]
cpu: Add IvyBridge-IBRS CPU model
This is a variant of IvyBridge with indirect branch prediction
protection. The only difference between IvyBridge and IvyBridge-IBRS is
the added "spec-ctrl" feature.
The IvyBridge-IBRS model in QEMU is a bit different since IvyBridge got
several additional features since we added it in cpu_map.xml:
arat, vme, xsaveopt
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 8 Jan 2018 19:53:25 +0000 (20:53 +0100)]
cpu: Add SandyBridge-IBRS CPU model
This is a variant of SandyBridge with indirect branch prediction
protection. The only difference between SandyBridge and SandyBridge-IBRS
is the added "spec-ctrl" feature.
The SandyBridge-IBRS model in QEMU is a bit different since SandyBridge
got several additional features since we added it in cpu_map.xml:
arat, vme, xsaveopt
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 8 Jan 2018 19:53:25 +0000 (20:53 +0100)]
cpu: Add Westmere-IBRS CPU model
This is a variant of Westmere with indirect branch prediction
protection. The only difference between Westmere and Westmere-IBRS is
the added "spec-ctrl" feature.
The Westmere-IBRS model in QEMU is a bit different since Westmere got
several additional features since we added it in cpu_map.xml:
arat, pclmuldq, vme
Adding them only to the -IBRS variant would confuse our CPU detection
code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Mon, 8 Jan 2018 19:53:25 +0000 (20:53 +0100)]
cpu: Add Nehalem-IBRS CPU model
This is a variant of Nehalem with indirect branch prediction protection.
The only difference between Nehalem and Nehalem-IBRS is the added
"spec-ctrl" feature.
Thus the diff matches QEMU, but the new CPU model itself is different.
The QEMU's versions of both models contain "vme" feature, while this
feature is missing in libvirt's models. While we can't change the
existing Nehalem CPU model, we could add "vme" to Nehalem-IBRS to make
it similar to QEMU, but doing so would fool our CPU detecting code so
that any Nehalem CPU with "vme" feature would be detected as
Nehalem-IBRS CPU without spec-ctrl. Not adding "vme" to Nehalem-IBRS is
safe as QEMU will just provide the feature anyway, which matches what
happens with Nehalem (and new enough machine types).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Fri, 5 Jan 2018 14:03:12 +0000 (15:03 +0100)]
cputest: Add data for Intel(R) Xeon(R) CPU E5-2623 v4
The CPU contains the updated microcode for CVE-2017-5715.
The *-guest.xml and *-json.xml CPU definitions use Skylake-Client CPU
model rather than Broadwell. This is similar to Xeon-E5-2650-v4 and it
is caused by our CPU model selection code when no model matches the CPU
signature (family + model). We'd need to maintain a complete list of CPU
signatures for our CPU models to fix this.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Marc Hartmayer [Wed, 17 Jan 2018 12:26:08 +0000 (13:26 +0100)]
qemu: Fix segmentation fault when attaching a non iSCSI host device
Add a check if it's a iSCSI hostdev and if it's not then don't use the
union member 'iscsi'. The segmentation fault occured when accessing
secinfo->type, but this can vary from case to case.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Update the min fedora to 26. Use a macro to record the min versions so that the
later error message is always in sync with the earlier version check. Clarify
the comment that refers to guessing of dist which does not actually happen.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Dan Zheng [Tue, 16 Jan 2018 04:21:21 +0000 (12:21 +0800)]
nodedev: Add the missing PCI dev checks for 'mdev_types' capability
Similar to commit @f44ec9c1, commit @500cbc06 introduced a new nested
'mdev_types' capability, however the mentioned commit didn't adjust
virNodeDeviceNumOfCaps and virNodeDeviceListCaps functions accordingly
to provide proper support for this capability.
After applying this patch the following python snippet returns the
expected results:
import libvirt
conn = libvirt.openReadOnly('qemu:///system')
devs = conn.listAllDevices()
for dev in devs:
if 'mdev_types' in dev.listCaps():
print dev.name(),dev.numOfCaps(),dev.listCaps()
Signed-off-by: Dan Zheng <dzheng@redhat.com> Signed-off-by: Erik Skultety <eskultet@redhat.com>
Michal Privoznik [Sun, 14 Jan 2018 13:29:32 +0000 (14:29 +0100)]
m4: Check for rl_completion_quote_character
Apparently we can't assume that people run readline recent enough
to have rl_completion_quote_character (added in readline-5.0
released in 2011). However, we can't compile without it. So if
not present, disable readline.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The functions defined in these sources are referenced all over
the place, however, compiler only when building with readline.
Thus when building without it linker gets sad as it can't find
them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Michal Privoznik [Sun, 14 Jan 2018 10:43:51 +0000 (11:43 +0100)]
vsh: Provide cmdComplete stub for readline disabled builds
When building without readline, this function does nothing but
return false. Without touching any of its arguments which
triggers a build error. Therefore, provide a stub that has
arguments marked as unused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Michal Privoznik [Fri, 12 Jan 2018 16:05:33 +0000 (17:05 +0100)]
vshReadlineOptionsGenerator: Don't add already specified options to the list
The current state of art is as follows:
1) vshReadlineOptionsGenerator() generate all possible --options
for given command, and then
2) vshReadlineOptionsPrune() clears out already provided ones
from the list.
Not only this brings needless memory complexity it is also not
trivial to get right. We can switch to easier approach: just
don't add already specified --options in the first step.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Andrea Bolognani [Fri, 12 Jan 2018 10:02:38 +0000 (11:02 +0100)]
travis: Sync packages with libvirt-jenkins-ci
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit 3a559ae7bc08.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Scott Garfinkle [Tue, 26 Dec 2017 19:55:08 +0000 (13:55 -0600)]
domcaps: Treat host models as case-insensitive strings
Qemu 2.11 allows case-insensitive specification of CPU models.
This patch fixes the resulting problems on (at least) POWER
arch machines so that Power8 and POWER8 are not different.
Signed-off-by: Scott Garfinkle <scottgar@linux.vnet.ibm.com>
Jiri Denemark [Thu, 11 Jan 2018 19:47:50 +0000 (20:47 +0100)]
qemu: Fix type of a completed job
Libvirt 3.7.0 and earlier libvirt reported a migration job as completed
immediately after QEMU finished sending migration data at which point
migration was not really complete yet. Commit v3.7.0-29-g3f2d6d829e
fixed this, but caused a regression in reporting statistics for
completed jobs which started reporting the job as still running. This
happened because the completed job statistics including the job status
are copied from the running job before we finally mark it as completed.
Let's make sure QEMU_DOMAIN_JOB_STATUS_COMPLETED is always set in the
completed job info even when the job has not finished yet.
Jiri Denemark [Wed, 10 Jan 2018 14:56:21 +0000 (15:56 +0100)]
qemu: Ignore fallback CPU attribute on reconnect
When reconnecting to a running domain with host-model CPU started by old
libvirt which did not store the actual CPU in the status XML, we need to
ignore the fallback attribute to make sure we can translate the detected
host CPU model to a model which is supported by the running QEMU.
Michal Privoznik [Thu, 11 Jan 2018 21:11:15 +0000 (22:11 +0100)]
m4: Don't enable bash-completion by default
Due to the way that check logic was written we basically enabled
bash completion whenever readline was enabled. This is not right
because it made bash-completion pkg-config module required.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
For given domain fetch list of defined interfaces. This can be
used for commands like domif-getlink and others. If available,
the interface name is returned (e.g. "vnet0", usually available
only for running domains), if not the MAC address is returned.
Moreover, the detach-interface command requires only MAC address
and therefore we have new flag that forces the completer to
return just the MAC address.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Tue, 31 Oct 2017 08:24:21 +0000 (09:24 +0100)]
virsh: Introduce virshDomainNameCompleter
Now that we have everything prepared let the fun begin. This
completer is very simple and returns domain names. Moreover,
depending on the command it can return just a subset of domains
(e.g. only running/paused/transient/.. ones).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This command is going to be called from bash completion script in
the following form:
virsh complete -- start --domain
Its only purpose is to return list of possible strings for
completion. Note that this is a 'hidden', unlisted command and
therefore there's no documentation to it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Fri, 29 Dec 2017 10:25:38 +0000 (11:25 +0100)]
vsh: Filter --options
Similarly to the previous commit, once we've presented an
--option for a command to the user it makes no sense to offer it
again. Therefore, we can prune all already specified options. For
instance, after this patch:
virsh # migrate --verbose <TAB><TAB>
will no longer offer --verbose option.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 28 Dec 2017 11:26:41 +0000 (12:26 +0100)]
vsh: Prune string list returned by completer
Instead of having completers prune returned string list based on
user's input we can do that right after the callback is called.
Only strings matching the prefix will be presented to the user
then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Tue, 21 Nov 2017 16:45:50 +0000 (17:45 +0100)]
vsh: Call vshCmdOptDef completer
Now that we have everything prepared we can call options'
completer again. At the same time, pass partially parsed input to
the completer callback - it will help the callbacks to narrow
down the list of returned options based on user's input. For
instance, if the completer is supposed to return list of
interfaces depending on user input it may return just those
interfaces defined for already specified domain. Of course,
completers might ignore this parameter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In the future, completer callbacks will receive partially parsed
command (and thus possibly incomplete). However, we still want
them to use command options fetching APIs we already have (e.g.
vshCommandOpt*()) and at the same time don't report any errors
(nor call any asserts).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
Michal Privoznik [Tue, 21 Nov 2017 16:23:11 +0000 (17:23 +0100)]
vshReadlineParse: Use string list
It's better to fetch list of either commands or options just once
and then iterate over it. Moreover, it makes future completers
way simpler as they will return string lists too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Mon, 13 Nov 2017 12:34:54 +0000 (13:34 +0100)]
vshReadlineParse: Escape returned results if needed
When returning a string that needs escaping there are two
scenarios that can happen. Firstly, user already started the
string with a quote (or double quote) in which case we don't need
to do anything - readline takes care of that. However, if they
haven't typed anything yet, we need to escape the string
ourselves.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
vshCommandStringParse: Allow retrieving partial result
In the future, this function is going to be called from
vshReadlineParse() to provide parsed input for completer
callbacks. The idea is to allow the callbacks to provide more
specific data. For instance, for the following input:
the --interface completer callback is going to be called. Now, it
is more user friendly if the completer offers only those
interfaces found in 'fedora' domain. But in order to do that it
needs to be able to retrieve partially parsed result.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Mon, 13 Nov 2017 13:46:36 +0000 (14:46 +0100)]
vshCommandParse: Don't leak @tkdata
When parsing cmd line which has "--" on it, this is leaked.
Problem is, parser->getNextArg() allocates new string and stores
it into tkdata. But as soon as "--" is detected 'continue' is
issued without any free of the allocated memory.
==5304== 3 bytes in 1 blocks are definitely lost in loss record 1 of 782
==5304== at 0x4C2AF50: malloc (vg_replace_malloc.c:299)
==5304== by 0x8BB5AA9: strdup (strdup.c:42)
==5304== by 0x55842CA: virStrdup (virstring.c:941)
==5304== by 0x172B21: _vshStrdup (vsh.c:162)
==5304== by 0x175E8E: vshCommandArgvGetArg (vsh.c:1622)
==5304== by 0x17551D: vshCommandParse (vsh.c:1418)
==5304== by 0x175F25: vshCommandArgvParse (vsh.c:1638)
==5304== by 0x130940: virshParseArgv (virsh.c:820)
==5304== by 0x130C49: main (virsh.c:922)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Bjoern Walk [Tue, 19 Dec 2017 10:08:01 +0000 (11:08 +0100)]
tests: virhostcputest: testcase for S390 system
Let's add a testcase for a S390 system running kernel version 4.14 on
LPAR.
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Bjoern Walk [Tue, 19 Dec 2017 10:08:00 +0000 (11:08 +0100)]
util: virhostcpu: parse frequency information on S390
Since kernel version 4.7, processor frequency information is available
on S390. Let's adjust the parser so this information shows up for virsh
nodeinfo:
# virsh nodeinfo
CPU model: s390x
CPU(s): 8
CPU frequency: 5000 MHz
CPU socket(s): 1
Core(s) per socket: 8
Thread(s) per core: 1
NUMA cell(s): 1
Memory size: 16273908 KiB
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
John Ferlan [Tue, 10 Oct 2017 22:32:40 +0000 (18:32 -0400)]
storage: Complete implementation volume by hash object
Alter the volume logic to use the hash tables instead of forward
linked lists. There are three hash tables to allow for fast lookup
by name, target.path, and key.
Modify the virStoragePoolObjAddVol to place the object in all 3
tables if possible using self locking RWLock on the volumes object.
Conversely when removing the volume, it's a removal of the object
from the various hash tables.
Implement functions to handle remote ForEach and Search Volume
type helpers. These are used by the disk backend in order to
facilitate adding a primary, extended, or logical partition.
Implement the various VolDefFindBy* helpers as simple (and fast)
hash lookups. The NumOfVolumes, GetNames, and ListExport helpers
are all implemented using standard for each hash table calls.
Alter the logic such that we only add the volume to the pool once
we've filled in all the information and cause failure to go to a
common error: label. Patches to place the @vol into a few hash tables
will soon "require" that at least the keys (name, target.path, and key)
be populated with valid data.
John Ferlan [Tue, 9 Jan 2018 13:40:24 +0000 (08:40 -0500)]
storage: When delete volume avoid disk backend removal
For a disk backend, the deleteVol code will clear all the
volumes in the pool and perform a pool refresh, thus the
storageVolDeleteInternal should not use access @voldef
after deleteVol succeeds.
Jiri Denemark [Fri, 5 Jan 2018 16:43:03 +0000 (17:43 +0100)]
cpu_x86: Copy CPU signature from ancestor
When specifying a new CPU model in cpu_map.xml as an extension to an
existing model, we forgot to copy the signature (family + model) from
the original CPU model.
We don't use this way of specifying CPU models, but it's still supported
and it becomes useful when someone wants to quickly hack up a CPU model
for testing or when creating additional variants of existing models to
help with fixing some spectral issues.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Fri, 5 Jan 2018 16:43:27 +0000 (17:43 +0100)]
cpu_x86: Add debug messages to x86DecodeUseCandidate
When translating CPUID data into CPU model + features, the code
sometimes uses an unexpected CPU model. There may be several reasons for
this, starting with wrong expectations and ending with an actual bug in
our code. These debug messages will help determining the reason.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Jiri Denemark [Fri, 5 Jan 2018 13:35:42 +0000 (14:35 +0100)]
cputest: Fix cpu-cpuid.py diff command
The cpuidMap in cpu-cpuid.py was created for converting old data files
(with QEMU's feature-words bits) to the new model-expansion based data.
When I added tests for CPU live update based on disabled/enabled feature
lists I shamelessly used the existing cpuidMap for generating the
*-{enabled,disabled}.xml data files. Thus any new CPUID bits which are
not present in the original cpuidMap would be ignored. The correct thing
to do is to use cpu_map.xml.
All data files were fixed by running the following command:
./cpu-cpuid.py diff *.json
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
projects / libvirt.git / log