priv and qemuCaps variables are not used anymore.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

This reverts commit 2841e675.

It turns out that adding the host_mtu field to the PCI capabilities in
the guest bumps the length of PCI capabilities beyond the 32 byte
boundary, so the virtio-net device gets 64 bytes of ioport space
instead of 32, which offsets the address of all the other following
devices. Migration doesn't work very well when the location and length
of PCI capabilities of devices is changed between source and
destination.

This means that we need to make sure that the absence/presence of
host_mtu on the qemu commandline always matches between source and
destination, which means that we need to make setting of host_mtu an
opt-in thing (it can't happen automatically when the bridge being used
has a non-default MTU, which is what commit 2841e675 implemented).

I do want to re-implement this feature with an <mtu auto='on'/>
setting, but probably won't backport that to any stable branches, so
I'm first reverting the original commit, and that revert can be pushed
to the few releases that have been made since the original (3.1.0 -
3.3.0)

Resolves: https://bugzilla.redhat.com/1449346

If a VNC listen address is not specified in domXML, libxl
will default to 127.0.0.1, but this is never reflected in the domXML.
In the case of spice, a missing listen address resulted in listening
on all interfaces, i.e. '0.0.0.0'. If not specified, set the listen
address in virDomainGraphicsDef struct to the libxl default when
creating the frame buffer device. Additionally, set default spice
listen address to 127.0.0.1.

Use a macro instead of hardcoding "127.0.0.1" throughout the
sources.

The current README file contents has almost no useful info, and that
which does exist is very outdated.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There's a slight problem with the current function. Assume we are
currently in a data section and we have say 42 bytes until next
section. Therefore, just before (handler) is called to fill up
the buffer with data, @want is changed to 42 to match the amount
of data left in the current section. However, after hole is
processed, we are back in data section but with incredibly small
@want size. Nobody will ever reset it back. This results in
incredible data fragmentation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 6fb5dd4f removed docs/archnetwork.html.in, but
left behind a pointer to it in docs/formatnetwork.html.in.

Update it so that it points to the wiki, which contains
more detailed and recent information anyway.

To every virDirOpen we must have VIR_DIR_CLOSE otherwise FD is
leaked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Only set releaseaddr to true after the address has been
reserved successfully.

https://bugzilla.redhat.com/show_bug.cgi?id=1452581Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The error message would contain first vcpu id after the list of vcpus
selected for modification. To print the proper vcpu id remember the
first vcpu selected to be modified.

@reply is a DBusMessage object returned by virDBusCallMethod in
get machine object call path, dereference it before calling
virDBusCallMethod again to get machine name.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Both variables for gcov and oom have wrong names inside configure.ac.
For this reason, the Test Suite configuration is not showing the current
configuration.

Before patching:
configure:    windres: no
configure:
configure: Test suite
configure:
configure:          Coverage:
configure:         Alloc OOM:
configure:
configure: Miscellaneous

After patching (using --enable-test-coverage and --enable-test-oom):
configure:    windres: no
configure:
configure: Test suite
configure:
configure:          Coverage: yes
configure:         Alloc OOM: yes
configure:
configure: Miscellaneous
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

It is possible to crash libvirtd when converting xl native config to
domXML when the xl config contains an empty disk source, e.g. an empty
CDROM. Fix by checking that the disk source is non-NULL before parsing it.
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>

On systems with older glibc including fcntl.h for getting
FALLOC_FL_PUNCH_HOLE defined is not enough. We must also include
linux/falloc.h.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Yet another place where we need to wrap code in
HAVE_DECL_SEEK_HOLE block.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some older systems (such as RHEL6) lack SEEK_HOLE and SEEK_DATA
which virFileInData relies on. Provide a stub for these systems.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Enums are unsigned, so it's impossible to check whether the helper
returned -1 for invalid conversions.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452454

Add explicit denies for disk devices to avoid cluttering dmesg with
(acceptable) denials.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Acked-by: NGuido Günther <agx@sigxcpu.org>

Allow access to libnl-3 config files
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Acked-by: NGuido Günther <agx@sigxcpu.org>

The code causes the 'offset' variable to be overwritten (possibly with
NULL if neither of the vCPUs is halted) which causes a crash since the
variable is still used after that part.

Additionally there's a bug, since strstr() would look up the '(halted)'
string in the whole string rather than just the currently processed line
the returned data is completely bogus.

Rather than switching to single line parsing let's remove the code
altogether since it has a commonly used JSON monitor alternative and
the data itself is not very useful to report.

The code was introduced in commit cc5e695b

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452106

There is a wrong 'return' statement after a 'goto' statement inside the
function virConnectCloseCallbackDataRegister(). This commit only removes
the 'return'.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

Currently, we don't assign any meaning to that. Our current view
on virStream is that it's merely a pipe. And pipes don't support
seeking.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

GCC 4.6 complains about a local declaration shadowing a global symbol.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Commit e3ba4025 introduced srv->handles and VIR_RESIZE_N to allocate
@handles as necessary, but did not free the handles during when calling
virNetlinkEventServiceStop.

Commit 15a71e60 introduced the virNetlinkEventServiceStopAll function, and
the code in virNetlinkEventServiceStop is copied to this function, so just
call virNetlinkEventServiceStop instead.

https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>

Start discovering the mediated devices on the host system and format the
attributes for the mediated device into the XML. Compared to the parent
device which reports generic information about the abstract mediated
devices types, a child device only reports the type name it has been
instantiated from and the IOMMU group number, since that's device
specific compared to the rest of the info that can be gathered about
mediated devices at the moment.
This patch introduces both the formatting and parsing routines, updates
nodedev.rng schema, adding a testcase as well.

The resulting mdev child device XML:
<device>
  <name>mdev_4b20d080_1b54_4048_85b3_a6a62d165c01</name>
  <path>/sys/devices/.../4b20d080-1b54-4048-85b3-a6a62d165c01</path>
  <parent>pci_0000_06_00_0</parent>
  <driver>
    <name>vfio_mdev</name>
  </driver>
  <capability type='mdev'>
    <type id='vendor_supplied_type_id'/>
    <iommuGroup number='NUM'/>
  <capability/>
<device/>

https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>

The parent device needs to report the generic stuff about the supported
mediated devices types, like device API, available instances, type name,
etc. Therefore this patch introduces a new nested capability element of
type 'mdev_types' with the resulting XML of the following format:

<device>
  ...
  <capability type='pci'>
    ...
    <capability type='mdev_types'>
      <type id='vendor_supplied_id'>
        <name>optional_vendor_supplied_codename</name>
        <deviceAPI>vfio-pci</deviceAPI>
        <availableInstances>NUM</availableInstances>
      </type>
        ...
      <type>
        ...
      </type>
    </capability>
  </capability>
  ...
</device>

https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>

The reason for introducing two capabilities, one for the device itself
(cap 'mdev') and one for the parent device listing the available types
('mdev_types'), is that we should be able to do
'virsh nodedev-list --cap' not only for existing mdev devices but also
for devices that support creation of mdev devices, since one day libvirt
might be actually able to create the mdev devices in an automated way
(just like we do for NPIV/vHBA).

https://bugzilla.redhat.com/show_bug.cgi?id=1452072Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since there's at least SRIOV and MDEV sub-capabilities to be parsed,
let's make the code more readable by splitting it to several logical
blocks.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Namely, this patch is about virMediatedDeviceGetIOMMUGroup{Dev,Num}
functions. There's no compelling reason why these functions should take
an object, on the contrary, having to create an object every time one
needs to query the IOMMU group number, discarding the object afterwards,
seems odd.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Commit 8e09663f "pci: recognize/report GEN4 (PCIe 4.0) card 16GT/s Link
speed" introduced another speed into enum, but mistakenly also altered
field width, so one bit of link width was included there.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Similarly to previous commit, implement sparse streams feature
for vol-upload. This is, however, slightly different approach,
because we must implement a function that will tell us whether
we are in a data section or in a hole. But there's no magic
hidden in here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new --sparse switch that does nothing more than
enables the sparse streams feature for this command. Among with
the switch new helper function is introduced: virshStreamSkip().
This is the callback that is called whenever daemon sends us a
hole. In the callback we reflect the hole in underlying file by
seeking as many bytes as told.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

These flags to APIs will tell if caller wants to use sparse
stream for storage transfer. At the same time, it's safe to
enable them in storage driver frontend and rely on our backends
checking the flags. This way we can enable specific flags only on
some specific backends, e.g. enable
VIR_STORAGE_VOL_DOWNLOAD_SPARSE_STREAM for filesystem backend but
not iSCSI backend.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now, not all APIs are going to support sparse streams. To some it
makes no sense at all, e.g. virDomainOpenConsole() or
virDomainOpenChannel(). To others, we will need a special flag to
indicate that client wants to enable sparse streams. Instead of
having to write RPC dispatchers by hand we can just annotate in
our .x files that a certain flag to certain RPC call enables this
feature. For instance:

     /**
      * @generate: both
      * @ReadStream: 1
      * @sparseflag: VIR_SPARSE_STREAM
      * @acl: storage_vol:data_read
      */
     REMOTE_PROC_DOMAIN_SOME_API = XXX,

Therefore, whenever client calls virDomainSomeAPI(..,
VIR_SPARSE_STREAM); daemon will mark that down and send stream
skips when possible.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Basically, what is needed here is to introduce new message type
for the messages passed between the event loop callbacks and the
worker thread that does all the I/O. The idea is that instead of
a queue of read buffers we will have a queue where "hole of size
X" messages appear. That way the event loop callbacks can just
check the head of the queue and see if the worker thread is in
data or a hole section and how long the section is.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Whenever client is able to receive some data from stream
daemonStreamHandleRead is called. But now the behaviour of this
function needs to be changed a bit. Previously it just read data
from underlying file (of chardev or whatever) and sent those
through the stream to client. This model will not work any longer
because it does not differentiate whether underlying file is in
data or hole section. Therefore, at the beginning of this
function add code that checks this situation and acts
accordingly.
So after the this, when wanting to send some data we always check
whether we are not in a hole and if so, skip it an inform client
about its size.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is fairly trivial now that we have everything in place.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>