define a VIR_DEFINE_AUTOPTR_FUNC() to autofree virNetworkPortDefs, and
convert all uses of virNetworkPortDefPtr that are appropriate to use
it.

This coincidentally fixes multiple potential memory leaks (in failure
cases) in networkPortCreateXML()
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

A virDomainNetDef object in a domain's nets array might contain a
virDomainHostdevDef, and when this is the case, the domain's hostdevs
array will also have a pointer to this embedded hostdev (this is done
so that internal functions that need to perform some operation on all
hostdevs won't leave out the type='hostdev' network interfaces).

When a network device was updated with virDomainUpdateDeviceFlags(),
we were replacing the entry in the nets array (and free'ing the
original) but forgetting about the pointer in the hostdevs array
(which would then point to the now-free'd hostdev contained in the old
net object.) This often resulted in a libvirtd crash.

The solution is to add a function, virDomainNetUpdate(), called by
qemuDomainUpdateDeviceConfig(), that updates the hostdevs array
appropriately along with the nets array.

Resolves: https://bugzilla.redhat.com/1558934Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The private data for video definition is created in
virDomainVideoDefNew() and we attempt to free it in
virDomainVideoDefFree(). This seems to work, except
the free function calls clear function which zeroes
out the whole structure and thus virObjectUnref()
which is called on private data does nothing.

2,568 bytes in 107 blocks are definitely lost in loss record 207 of 213
   at 0x4A35476: calloc (vg_replace_malloc.c:752)
   by 0x50A6048: virAllocVar (viralloc.c:346)
   by 0x513CC5A: virObjectNew (virobject.c:243)
   by 0x4DC1DEE: qemuDomainVideoPrivateNew (qemu_domain.c:1337)
   by 0x51A6BD6: virDomainVideoDefNew (domain_conf.c:2831)
   by 0x51B9F06: virDomainVideoDefParseXML (domain_conf.c:15541)
   by 0x51CB761: virDomainDefParseXML (domain_conf.c:21158)
   by 0x51C5973: virDomainDefParseNode (domain_conf.c:21708)
   by 0x51C583A: virDomainDefParse (domain_conf.c:21663)
   by 0x51C58AE: virDomainDefParseFile (domain_conf.c:21688)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

In bc1e924c we've introduced video driver name and whilst
doing so we've utilized VIR_ENUM_IMPL() macro. Then, in domain
XML parsing code the generated
virDomainVideoBackendTypeFromString() is called and its return
value is assigned directly to an unsigned int variable which is
wrong. Also, the video driver enum has 'default' value which is
not formatted into domain XML but is accepted during parsing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

Add qemuVhostUserFetchConfigs() to discover vhost-user helpers.

qemuVhostUserFillDomainGPU() will find the first matching GPU helper
with the required capabilities and set the associated
vhost_user_binary.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

vhost-user-gpu helper takes --render-node option to specify on which
GPU should the renderning be done.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Accept a new driver name attribute to specify usage of helper process, ex:

  <video>
    <driver name='vhostuser'/>
    <model type='virtio'/>
  </video>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When the bridge re-attach handling was moved out of the network driver
and into the hypervisor driver (commit b806a60e) as a part of the
refactor to split the network driver into a separate daemon, the check
was accidentally changed to only check for type='bridge'. The check for
type in this case needs to check for type='network' as well.

(at the time we thought that the two types could be conflated for
interface actual type, but this turned out to be too problematic to
do).
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Use VIR_AUTOPTR for temporary locals and get rid of the cleanup label.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Refactor functions using these two object types together with
VIR_AUTOPTR.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Clean up functions which grab and free the context to use VIR_AUTOPTR.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use VIR_AUTO* helpers to get rid of the convoluted cleanup path.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The wrapper reports libvirt errors for the libxml2 function so that
the same does not have to be repeated over and over.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

It needs to be used by a function that only has a const pointer to
virDomainNetDef.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The virNetworkPortDef config stores the 'managed' attribute
as the virTristateBool type.

The virDomainDef config stores the 'managed' attribute as
the bool type.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

If the hypervisor driver has not yet created the network port, the
portid field will be "00000000-0000-0000-0000-000000000000".

If a failure occurs during early VM startup, the hypervisor driver may
none the less try to release the network port, resulting in an
undesirable warning:

2019-09-12 13:17:42.349+0000: 16544: error :
virNetworkObjLookupPort:1679 : network port not found: Network port with
UUID 00000000-0000-0000-0000-000000000000 does not exist

By checking if the portid UUID is valid, we can avoid polluting the logs
in this way.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The function virDomainDefFormatInternal() has the predefined root name
"domain" to format the XML. But to save both active and inactive domain
in the snapshot XML, the new root name "inactiveDomain" was created.
So, the new function virDomainDefFormatInternalSetRootName() allows to
choose the root name of XML. The former function became a tiny wrapper
to call the new function setting the correct parameters.
Signed-off-by: NMaxiwell S. Garcia <maxiwell@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The only caller for which this check makes sense is virDomainDefParse.
Thus the check should be moved there.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@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>

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>

After parsing a video device with a model type of
VIR_DOMAIN_VIDEO_TYPE_NONE, all device info is cleared (see
virDomainDefPostParseVideo()) in order to avoid formatting any
auto-generated values for the XML. Subsequently, however, an alias is
generated for the video device (e.g. 'video0'), which results in an
alias property being formatted in the XML output anyway. This creates
confusion if the user has explicitly provided an alias for the video
device since the alias will change.

To avoid this, don't clear the user-defined alias for video devices of
type "none".

https://bugzilla.redhat.com/show_bug.cgi?id=1720612Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The attribute is named 'secret', not 'uuid'
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Now that virDomainXMLNamespace matches virXMLNamespace,
we no longer need to keep both around.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

In the future we will perform more actions if ns.parse
is present. Decouple the condition from the actual call.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

We do not need to pass the root node, since it's already
included in the XPathContext.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Neither the xmlDocPtr nor the root xmlNode (also passed
in the XPathContext) are interesting to the callees.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

resctrl object stored in def->resctrls is shared by cachetune and
memorytune. The domain xml configuration is parsed firstly for
cachetune then memorytune, and the resctrl object will not be created
in parsing settings for memorytune once it found sharing exists.

But resctrl is improperly freed when sharing happens.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Support 'Direct Mode' for Hyper-V Synthetic Timers in domain config.
Make it 'stimer' enlightenment option as it is not a separate thing.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The only code path which calls the parser with the
VIR_DOMAIN_DEF_PARSE_DISK_SOURCE is from qemuDomainBlockCopy. Since that
code path can properly handle backing chains for the disk and it's
desired to pass the parsed chains to the block copy code remove the
condition which prevents parsing the <backingStore> element.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

QEMU version 2.12.1 introduced a performance feature under commit
be7773268d98 ("target-i386: add KVM_HINTS_DEDICATED performance hint")

This patch adds a new KVM feature 'hint-dedicated' to set this performance
hint for KVM guests. The feature is off by default.

To enable this hint and have libvirt add "-cpu host,kvm-hint-dedicated=on"
to the QEMU command line, the following XML code needs to be added to the
guest's domain description in conjunction with CPU mode='host-passthrough'.

  <features>
    <kvm>
      <hint-dedicated state='on'/>
    </kvm>
  </features>
  ...
  <cpu mode='host-passthrough ... />
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
Signed-off-by: NMenno Lageman <menno.lageman@oracle.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Redefining a domain via virDomainDefineXML should not give different results
based on an already existing definition.

Also, there's a crasher somewhere in the code:
https://bugzilla.redhat.com/show_bug.cgi?id=1739338

This reverts commit 94b3aa55Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Since its introduction in commit
8737578d, the TPM version format is
"2.0" and not "2".
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since qemuDomainDeviceDefPostParse callback requires qemuCaps, we need
to make sure it gets the capabilities stored in the domain's private
data if the domain is running. Passing NULL may cause QEMU capabilities
probing to be triggered in case QEMU binary changed in the meantime.
When this happens while a running domain object is locked, QMP event
delivered to the domain before QEMU capabilities probing finishes will
deadlock the event loop.

QEMU capabilities lookup (via domainPostParseDataAlloc callback) is
hidden inside virDomainDeviceDefPostParseOne with no way to pass
qemuCaps to virDomainDeviceDef* functions. This patch fixes all
remaining paths leading to virDomainDeviceDefPostParse.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.

Several general functions from domain_conf.c were lazily passing NULL as
the parseOpaque pointer instead of letting their callers pass the right
data. This patch fixes all paths leading to virDomainDefCopy to do the
right thing.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Current code doesn't allow us to add sub-features as we always print the
closing '/>'. As a preparatory change to implementing 'direct' sub-feature
for 'stimer' feature switch to printing closing tag individually.

No functional change.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>