If user is trying to auto complete a value that contains a space,
they have two options: use backslash to escape space or use
quotes, like this:
virsh # start --domain "domain with space<TAB>
However, in this case our tokenizer sees imbalance in (double)
quotes: there is a starting one that's missing its companion.
Well, that's obvious - user is still in process of writing the
command. What we need to do in this case is to ignore the
imbalance and return success (from the tokenizer) - readline will
handle closing the quote properly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way that auto completion works currently is that user's input
is parsed, and then we try to find the first --option (in the
parsed structure) that has the same value as user's input around
where <TAB> was pressed. For instance, for the following input:
virsh # command --arg1 hello --arg2 world<TAB>
we will see "world" as text that user is trying to autocomplete
(this is affected by rl_basic_word_break_characters which
readline uses internally to break user's input into individual
words) and find that it is --arg2 that user is trying to
autocomplete. So far so good, for this naive approach. But
consider the following example:
virsh # command --arg1 world --arg2 world<TAB>
Here, both arguments have the same value and because we see
"world" as text that user is trying to autocomplete we would
think that it is --arg1 that user wants to autocomplete. This is
obviously wrong.
Fortunately, readline stores the current position of cursor (into
rl_point) and we can use that when parsing user's input: whenever
we reach a position that matches the cursor then we know that
that is the place where <TAB> was pressed and hence that is the
--option that user wants to autocomplete. Readline stores the
cursor position as offset (numbered from 1) from the beginning of
user's input. We store this input into @parser->pos initially,
but then advance it as we tokenize it. Therefore, what we need is
to store the original position too.
Thanks to Martin who helped me with this.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way our completer callbacks work is that they return all
possible candidates and then vshCompleterFilter() is called to
prune the list of all candidates removing those which don't match
user's input. This allows us to have simpler completer callbacks
as their only job is to fetch all possible candidates.
Anyway, if the completion candidate we're returning contains a
space, it has to be escaped (shell like escaping), unless there
is already a quote character (single quote or double quote).
But ordering is critical. Completer callback returns string
without any escaping, but the filter function sees the user input
escaped. For instance, if user's input is "domain with
space<TAB>" then the filtering function gets "domain\ with\
space" as user's input but completer returns "domain with space".
Since these two strings don't match the filtering function
removes this candidate from the list. What we need to do is to
escape strings before calling the filtering function. This way,
the filtering function will see two same strings.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In next commit the block that does escaping of returned string
will be brought into this block. But both contain variable @buf
and use it in different contexts. Rename @buf from @state == 0
block to @line which reflects its purpose better.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Instead of freeing @partial and @buf explicitly, we can use
g_auto*() to do that automatically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On readline completion vshReadlineCompletion() is called which
does nothing more than calling rl_completion_matches() with
vshReadlineParse() as a callback. This means, that
vshReadlineParse() is called repeatedly, each time returning next
completion candidate, until it returns NULL which is interpreted
as the end of the list of candidates.
The function takes two parameters: @text which is a portion of
input line around cursor when TAB was pressed, and @state. The
@state is an integer that is zero on the very first call and
non-zero on each subsequent call (in fact, readline does @state++
on each call).
Anyway, the idea is that the callback gets the whole list of
candidates on @state == 0 and returns one candidate at each call.
And this is what vshReadlineParse() is doing but some variables
(@partial, @cmd and @opt) are really used only in the @state == 0
case but declared for whole function. We can limit their scope by
declaring them inside the @state == 0 body which also means that
they don't have to be static anymore.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
A backslash is the way we escape characters in virsh. For
instance:
virsh # start domain\ with\ long\ name
For readline completion, we do not want to get four separate
words ("domain", "with", "long", "name"). This means, that we
can't use virBufferEscapeShell() because it doesn't escape spaces
the way we want.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This variable is unused since introduction of the function in
v0.8.5~150.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As explained in QEMU commit 4c257911dcc7c4189768e9651755c849ce9db4e8
intel-pt features should never be included in the CPU models as it was
not supported by KVM back then and even once it started to be supported,
users have to enable it by passing pt_mode=1 parameter to kvm_intel
module. The Icelake-* CPU models with intel-pt included were added to
QEMU 3.1.0 and removed right in the following 4.0.0 release (and even in
3.1.1 maintenance release).
In libvirt 6.10.0 I introduced 'removed' attribute for features included
in our CPU model definitions which we can use to drop intel-pt from
Icelake-* CPU models. Back then I explained we can safely do so only for
features which could never be enabled, which is not the case of intel-pt.
Theoretically, it could be possible to create an environment in which
QEMU would enable intel-pt without asking for it explicitly: it would
need to use a new enough kernel (not available at the time of QEMU
3.1.0) and pt_mode KVM parameter in combination with QEMU 3.1.0 running
a domain with q35 machine type and all that on a CPU which didn't really
exist at that time.
Migrating such domain to a host with newer SW stack including libvirt
with this patch applied would result in incompatible guest ABI (the
virtual CPU would lose intel-pt). However, QEMU changed its CPU models
unconditionally and thus migration would not work even without this
patch. That said, it is safe to follow QEMU and remove the feature from
Icelake-* CPU models in our cpu_map.
https://bugzilla.redhat.com/show_bug.cgi?id=1853972
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The code block on the srv name in the formatnetwork page is confusing
since the actual parameter is service. Moving the code block to the
service work makes it better.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cédric Bosdonnat <cbosdonnat@suse.com>
Fedora 34 rawhide has pulled in a new GCC 11 build which now
defaults to dwarf5 format. This format is not compatible with
the pdwtags program used in our test suite to validate the
RPC files.
We have no need for debuginfo in CI except for pdwtags,
so the simplest short term fix is to force the older dwarf
version in the hope that a fixed dwarves release will
arrive before Fedora 34 is released, or GCC 11 becomes more
widespread. Eventually we might need to figure out a way to
probe for compatibility but for now, we'll hope that any
distro with GCC 11 will be able to have a fixed dwarves too.
https://bugzilla.redhat.com/show_bug.cgi?id=1919965
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
dtrace is now also installed when cross-building.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
dtrace invokes the C compiler, so when cross-building we need
to make sure that $CC is set in the environment and that it
points to the cross-compiler rather than the native one.
Until https://github.com/mesonbuild/meson/issues/266
is addressed, the workaround is to call dtrace via env(1).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980334
Signed-off-by: Helmut Grohne <helmut@subdivi.de>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
virPCIGetNetName is used to get the name of the netdev associated with
a particular PCI device. This is used when we have a VF name, but need
the PF name in order to send a netlink command (e.g. in order to
get/set the MAC address of the VF).
In simple cases there is a single netdev associated with any PCI
device, so it is easy to figure out the PF netdev for a VF - just look
for the PCI device that has the VF listed in its "virtfns" directory;
the only name in the "net" subdirectory of that PCI device's sysfs
directory is the PF netdev that is upstream of the VF in question.
In some cases there can be more than one netdev in a PCI device's net
directory though. In the past, the only case of this was for SR-IOV
NICs that could have multiple PF's per PCI device. In this case, all
PF netdevs associated with a PCI address would be listed in the "net"
subdirectory of the PCI device's directory in sysfs. At the same time,
all VF netdevs and all PF netdevs have a phys_port_id in their sysfs,
so the way to learn the correct PF netdev for a particular VF netdev
is to search through the list of devices in the net subdirectory of
the PF's PCI device, looking for the one netdev with a "phys_port_id"
matching that of the VF netdev.
But starting in kernel 5.8, the NVIDIA Mellanox driver began linking
the VFs' representor netdevs to the PF PCI address [1], and so the VF
representor netdevs would also show up in the net
subdirectory. However, all of the devices that do so also only have a
single PF netdev for any given PCI address.
This means that the net directory of the PCI device can still hold
multiple net devices, but only one of them will be the PF netdev (the
others are VF representors):
$ ls '/sys/bus/pci/devices/0000:82:00.0/net'
ens1f0 eth0 eth1
In this case the way to find the PF device is to look at the
"phys_port_name" attribute of each netdev in sysfs. All PF devices
have a phys_port_name matching a particular regex
(p[0-9]+$)|(p[0-9]+s[0-9]+$)
Since there can only be one PF in the entire list of devices, once we
match that regex, we've found the PF netdev.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/
commit/?id=123f0f53dd64b67e34142485fe866a8a581f12f1
Co-Authored-by: Moshe Levi <moshele@nvidia.com>
Signed-off-by: Dmytro Linkin <dlinkin@nvidia.com>
Reviewed-by: Adrian Chiris <adrianc@nvidia.com>
Reviewed-by: Laine Stump <laine@redhat.com>
This commit add virNetDevGetPhysPortName to read netdevice
phys_port_name from sysfs. It also refactor the code so
virNetDevGetPhysPortName and virNetDevGetPhysPortID will use
same method to read the netdevice sysfs.
Signed-off-by: Moshe Levi <moshele@nvidia.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Tests time out when building in slow environments, like emulated
s390x in Fedora copr. Bump up the test timeout
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fixes a memory leak when hypervCreateInvokeParamsList() fails.
Signed-off-by: Matt Coleman <matt@datto.com>
Reviewed-by: Laine Stump <laine@redhat.com>
