Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

There are two 'cleanup' labels - one in
virQEMUDriverConfigHugeTLBFSInit() and the other in
virQEMUDriverConfigSetDefaults() that do nothing more than
return and integer value. No memory freeing or anything important
is done there. Drop them in favour of returning immediately.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Our naming rules prefer qemuObjectOperation() scheme rather than
qemuOperationObject() for function names. These were not honoured
in recent commits to qemu_conf.c.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Traditionally, macvtap devices are supported using <interface
type='direct'>, but that type requires specifying a source device name
and macvtap mode which can't be altered after the initial device
creation (and may not even be available to the management software
that's creating the XML config to feed to libvirt).

But the attributes in the <source> are essentially describing how the
device will be connected to the network, and if libvirt is to be
supplied with the name of a macvtap device that has already been
created, that device will also already be connected to the network
(and the connection can't be changed). Thus it seems more appropriate
to use type='ethernet', which was created explicitly for this purpose
- for devices that have already been (or will be) connected to the
external network by someone/something outside of libvirt. The fact
that it is a *macv*tap rather than a contentional tap device is just a
detail.

This patch supports using an existing macvtap device with <interface
type='ethernet'> by checking the supplied target dev name to see if it
is a macvtap device and, when this is the case, calling
virNetDevMacVLanTapOpen() instead of virNetDevTapCreate(). For
consistency, this is only done when target managed='no'.

Resolves: https://bugzilla.redhat.com/1723367 (partially)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If managed='no', then the tap device must already exist, and setting
of MAC address and online status (IFF_UP) is skipped.

NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate,
because those bits must be properly set in the TUNSETIFF we use to set
the tap device name of the handle we've opened - if IFF_VNET_HDR has
not been set and we set it the request will be honored even when
running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be
different than how it was created, that will result in an error from
the kernel. This means that you don't need to pay attention to
IFF_VNET_HDR when creating the tap devices, but you *do* need to set
IFF_MULTI_QUEUE if you're going to use multiple queues for your tap
device.

NB2: /dev/vhost-net normally has permissions 600, so it can't be
opened by an unprivileged process. This would normally cause a warning
message when using a virtio net device from an unprivileged
libvirtd. I've found that setting the permissions for /dev/vhost-net
permits unprivileged libvirtd to use vhost-net for virtio devices, but
have no idea what sort of security implications that has. I haven't
changed libvrit's code to avoid *attempting* to open /dev/vhost-net -
if you are concerned about the security of opening up permissions of
/dev/vhost-net (probably a good idea at least until we ask someone who
knows about the code) then add <driver name='qemu'/> to the interface
definition and you'll avoid the warning message.

Note that virNetDevTapCreate() is the correct function to call in the
case of an existing device, because the same ioctl() that creates a
new tap device will also open an existing tap device.

Resolves: https://bugzilla.redhat.com/1723367 (partially)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Although <interface type='ethernet'> has always been able to use an
existing tap device, this is just a coincidence due to the fact that
the same ioctl is used to create a new tap device or get a handle to
an existing device.

Even then, once we have the handle to the device, we still insist on
doing extra setup to it (setting the MAC address and IFF_UP).  That
*might* be okay if libvirtd is running as a privileged process, but if
libvirtd is running as an unprivileged user, those attempted
modifications to the tap device will fail (yes, even if the tap is set
to be owned by the user running libvirtd). We could avoid this if we
knew that the device already existed, but as stated above, an existing
device and new device are both accessed in the same manner, and
anyway, we need to preserve existing behavior for those who are
already using pre-existing devices with privileged libvirtd (and
allowing/expecting libvirt to configure the pre-existing device).

In order to cleanly support the idea of using a pre-existing and
pre-configured tap device, this patch introduces a new optional
attribute "managed" for the interface <target> element. This
attribute is only valid for <interface type='ethernet'> (since all
other interface types have mandatory config that doesn't apply in the
case where we expect the tap device to be setup before we
get it). The syntax would look something like this:

   <interface type='ethernet'>
      <target dev='mytap0' managed='no'/>
      ...
   </interface>

This patch just adds managed to the grammar and parser for <target>,
but has no functionality behind it.

(NB: when managed='no' (the default when not specified is 'yes'), the
target dev is always a name explicitly provided, so we don't
auto-remove it from the config just because it starts with "vnet"
(VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the
same pattern of names that libvirt itself uses when it automatically
creates the tap devices.)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This will simplify addition of another attribute to the <target> element
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This just moves around a few things in qemuInterfaceConnect() with no
functional difference (except that a few failures that would have
previously resulted in a "success" audit log will now properly produce
a "fail" audit). The change is so that adding support for unmanaged
tap/macvtap devices will be more easily reviewable.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

In virNetDevMacVLanOpen(), The "retries" arg has been removed and the
value hardcoded as 10, since previously the function was only called
from one place, so it was always 10.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This function returns T if the given name is a macvtap device. This is
determined by 1) getting the ifindex of the device with that name (if
there is one), and 2) checking for existence of /dev/tapXX, where "XX"
is the ifindex learned in (1).

It's also possible to learn this by getting a netlink dump of the
interface and parsing through it to look for some attributes, but that
is complicated to figure out, takes longer to execute, and I'm lazy.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This patch adds hostdev test cases in qemuhotplugtest.c.

Note: the small tweak inside virpcimock.c was needed because
the new tests added a code path in which virHostHasIOMMU()
(virutil.c) started being called, and the mocked '/sys/kernel/'
prefix that is mocked in virpcimock.c wasn't being considered
in the opendir() mock. An alternative to avoid these situations
in virpcimock.c is implemented in the next patch.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

When starting a domain, we use the presence of a vfio-pci or
mdev hostdev to determine if the memlock maximum needs to be
increased.  But if we hotplug either of these devices, only the
vfio-pci path gets that love.  This means that attaching a, say,
vfio-ccw device will appear to succeed but the device may be
unusable as the guest may see I/O errors on long CCW chains.
The host, meanwhile, would be flooded with these messages:

  vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded

Let's adjust the maximum memlock value in the mdev hotplug path,
so that the domain has the same value as if it were started with
one or more mdev devices in its configuration.
Signed-off-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

If attaching a PCI hostdev fails, there are several things that
need to be un-done as part of the cleanup.  One thing that is
not done is re-calculating/re-setting the maximum amount of locked
memory for the domain, since we may have changed that.

Let's fix that, just to ensure everything is back the way it was.
Signed-off-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Let's pull this hunk out into a function, so it can be reused
in another codepath that needs to do the same thing.
Signed-off-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

In f08e6883 I've made @pcidevs in
virHostdevReAttachPCIDevices() to be automatically unrefed using
VIR_AUTOUNREF() but I forgot to remove the line that explicitly
unrefs the object at the end of the function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After the previous commits, qemuAddSharedDevice() and
qemuRemoveSharedDevice() are now the same code with a different
flag to call the internal functions.

This patch aggregates the common code into a new function called
qemuAddRemoveSharedDeviceInternal() to further reduce
code repetition. Both qemuAddSharedDevice() and
qemuRemoveSharedDevice() are kept since they are public
functions used elsewhere.

No functional change was made.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Following the same idea of avoid code repetition from the
previous patch, this commit introduces a new function that
aggregates the functions of qemuAddSharedDisk() and
qemuRemoveSharedDisk() into a single place, using a flag to
switch between add/remove operations.

Both qemuAddSharedDisk() and qemuRemoveSharedDisk() are
public, so keep them around to avoid changing other files
due to an internal qemu_conf.c refactory.

No functional change was made.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

qemuAddSharedHostdev() has a code similar to
qemuRemoveSharedHostdev(), with exception of one line that
defines the operation (add or remove).

This patch introduces a new function that aggregates the common
code, using a flag to switch between the operations, avoiding
code repetition.

No functional change was made.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Since commit fd9ef3b3, virDomainFindByUUIDRef() no longer exists and
all virDomainObjListFindBy*() functions now increment the reference
count.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

As a result of changes in

      commit d5f0c1b6
      Author: Daniel P. Berrangé <berrange@redhat.com>
      Date:   Thu Jul 18 12:30:22 2019 +0100

        remote: stop trying to print help as giant blocks of text

The socket path built would be libvirt//var/run/libvirt-sock
instead of /var/run/libvirt/libvirt-sock. Fortunately this only
affects users who have set the 'unix_sock_dir' config parameter
in /etc/libvirt/libvirtd.conf, which is pretty rare/unusual.
Signed-off-by: Neater <=@eater.me>

Exception made for the psuedonym above since patch is considered
trivial & thus non-copyrightable material.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

In some places where virDomainObjListForEach() is called the
passed callback calls virDomainObjListRemoveLocked(). Well, this
is unsafe, because the former only grabs a read lock but the
latter modifies the list.
I've identified the following unsafe calls:

- qemuProcessReconnectAll()
- libxlReconnectDomains()

The rest seem to be safe.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The @cmdstr variable is not used really.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

virDomainObjCheckActive() returns -1 if domain is not active, not 0.

Fixes cb50436c "libxl: implement virDomainPM* functions"
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

This is an issue for LXC loop devices when you are trying to get loop
devices info using `ioctl`. Modern apps uses `/sys/dev/block` to grab
information about devices, but if you use the method mention you won't
be able to retrive the associated file with that loop device. See
example below from cryptsetup sources:

    static char *_ioctl_backing_file(const char *loop)
    {
        struct loop_info64 lo64 = {0};
        int loop_fd;

        loop_fd = open(loop, O_RDONLY);
        if (loop_fd < 0)
            return NULL;

        if (ioctl(loop_fd, LOOP_GET_STATUS64, &lo64) < 0) {
            close(loop_fd);
            return NULL;
        }

        lo64.lo_file_name[LO_NAME_SIZE-2] = '*';
        lo64.lo_file_name[LO_NAME_SIZE-1] = 0;

        close(loop_fd);
        return strdup((char*)lo64.lo_file_name);
    }

It will return an empty string because lo_file_name was not set.
Function `virFileLoopDeviceOpenSearch()` is using `ioctl` to query data,
but it is not checking `lo_file_name` field.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When the network interface is of "user" type, and QEMU has the "-net
socket,fd=" datagram support, call qemuInterfacePrepareSlirp() to
probe and associate a slirp-helper with the interface.

The usage of automated slirp-helper can be prevented with
disableSlirp (in particular when resuming a
VM that didn't start with slirp-helper before).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If a slirp-helper is associated with a network interface (after
probing & preparing succesfully), pass the socket fd to QEMU and use
"-net socket,fd=".
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If a slirp-helper is associated with a network interface,
prepare/start/stop the process via qemu-extdevice.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

For VM started and migrated/saved without slirp-helpers, let's prevent
the automatic setup (as it would fail to migrate otherwise).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Save & restore the slirp helper PID associated with a network
interface & the probed features.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The unit provides the functions associated with a slirp-helper:
- probing / checking capabilities
- opening the socketpair
- starting / stoping the helper
- registering for dbus-vmstate migration
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

A slirp helper is a process that provides user-mode networking through
a unix domain socket. It is expected to follow the following
specification:
https://gitlab.freedesktop.org/slirp/libslirp-rs/blob/master/src/bin/README.rstSigned-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>