This function will fetch previously processed stream holes and
return their sum.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Now that we have RPC wrappers over VIR_NET_STREAM_HOLE we can
start wiring them up. This commit wires up situation when a
client wants to send a hole to daemon.

To keep stream offsets synchronous, upon successful call on the
daemon skip the same hole in local part of the stream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is a function that handles an incoming STREAM_HOLE packet.
Even though it is not wired up yet, it will be soon. At the
beginning do couple of checks whether server plays nicely and
sent us a STREAM_HOLE packed only after we've enabled sparse
streams. Then decodes the message payload to see how big the hole
is and stores it in passed @length argument.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Basically, whenever the new type of stream packet arrives to the
daemon call this function that decodes it and calls
virStreamSendHole(). Otherwise a regular data stream packet has
arrived and therefore continue its processing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While the previous commit implemented a helper for sending a
STREAM_HOLE packet for daemon, this is a client's counterpart.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just a helper function that takes in a length value,
encodes it into XDR and sends to client.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Ideally, this would be generated, but to achieve that
corresponding XDR definitions needed to go into a different .x
file. But they belong just to the one that they are right now.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is a special type of stream packet, that is bidirectional
and contains information regarding how many bytes each side will
be skipping in the stream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is going to be RPC representation for virStreamSendHole.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new argument to daemonCreateClientStream in order to allow for
future expansion to mark that a specific stream can be used to skip
data, such as the case with sparsely populated files. The new flag will
be the eventual decision point between client/server to decide whether
both ends can support and want to use sparse streams.

A new bool 'allowSkip' is added to both _virNetClientStream and
daemonClientStream in order to perform the tracking.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a virStreamPtr pointer to the _virNetClientStream
in order to reverse track the parent stream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just an internal API, that calls corresponding function
in stream driver. This function will set @data = 1 if the
underlying file is in data section, or @data = 0 if it is in a
hole. At any rate, @length is set to number of bytes remaining in
the section the file currently is.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just a wrapper over new function that have been just
introduced: virStreamSendHole() . It's very similar to
virStreamSendAll() except it handles sparse streams well.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just a wrapper over new functions that have been just
introduced: virStreamRecvFlags(), virStreamRecvHole(). It's very
similar to virStreamRecvAll() except it handles sparse streams
well.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new flag to virStreamRecvFlags in order to handle being able to
stop reading from the stream so that the consumer can generate a "hole"
in stream target. Generation of a hole replaces the need to receive and
handle a sequence of zero bytes for sparse stream targets.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function is basically a counterpart for virStreamSendHole().
If one side of a stream called virStreamSendHole() the other
should call virStreamRecvHole() to get the size of the hole.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This API is used to tell the other side of the stream to skip
some bytes in the stream. This can be used to create a sparse
file on the receiving side of a stream.

It takes @length argument, which says how big the hole is. This
skipping is done from the current point of stream. Since our
streams are not rewindable like regular files, we don't need
@whence argument like seek(2) has.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There are three virStreamDriver's currently supported:

 * virFDStream
 * remote driver
 * ESX driver

For now, backend virStreamRecvFlags support for only remote driver and
ESX driver is sufficient. Future patches will update virFDStream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch is adding the virStreamRecvFlags as a variant to the
virStreamRecv function in order to allow for future expansion of
functionality for processing sparse streams using a @flags
argument.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function takes a FD and determines whether the current
position is in data section or in a hole. In addition to that,
it also determines how much bytes are there remaining till the
current section ends.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

One big downside of using the pipe to transfer the data is that
we can really transfer just bare data. No metadata can be carried
through unless some formatted messages are introduced. That would
be quite painful to achieve so let's use a message queue. It's
fairly easy to exchange info between threads now that iohelper is
no longer used.

The reason why we cannot use the FD for plain files directly is
that despite us setting noblock flag on the FD, any
read()/write() blocks regardless (which is a show stopper since
those parts of the code are run from the event loop) and poll()
reports such FD as always readable/writable - even though the
subsequent operation might block.

The pipe is still not gone though. It is used to signal the event
loop that an event occurred (e.g. data is available for reading
in the queue, or vice versa).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

virt-install and virt-manager both default to explicitly setting
"io='native'" in the disk "driver" tag. virsh, however, does not and also
does not provide an option to specify that setting at all.  As a result,
disks use a different IO mechanism (the default, "threads") when attached
post-setup using virsh.  Adding this option allows users to keep disk
performance consistent for disks attached at install, and those attached
afterward.

Since we allow active layer block commit the users are allowed to commit
the top of the chain (e.g. vda) into the backing image. The API would
not accept that parameter, as it tried to look up the image in the
backing chain.

Add the ability to use the top level image target name explicitly as the
top image of the block commit operation.

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

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The QEMU default is GICv2, and some of the code in libvirt
relies on the exact value. Stop pretending that's not the
case and use GICv2 explicitly where needed.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

There are currently some limitations in the emulated GICv3
that make it unsuitable as a default. Use GICv2 instead.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1450433Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Currently we consider all UNIX paths with specific prefix as generated
by libvirt, but that's a wrong assumption.  Let's make the detection
better by actually checking whether the whole path matches one of the
paths that we generate or generated in the past.

The UNIX path isn't stored in config XML since libvirt-1.3.1.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446980Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The debian etch distro was end-of-life a long time ago so we no
longer need the ULLONG_MAX hack. In any case gnulib now provides
an equivalent fix by default, and so our definition now triggers
syntax-check rule failure

src/internal.h:#    define ULLONG_MAX   ULONG_LONG_MAX
maint.mk: define the above via some gnulib .h file
maint.mk:843: recipe for target 'sc_prohibit_always-defined_macros' failed
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This pulls in the fixes for poll() on Win32 which finally
makes the remote driver work again.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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

Format the caching-mode option for the intel-iommu device,
based on its <driver caching> attribute value.

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

Add a new attribute to control the caching mode.

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

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

Add a new attribute to control interrupt remapping.

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

Add kernel_irqchip=split/on to the QEMU command line
and a capability that looks for it in query-command-line-options
output. For the 'split' option, use a version check
since it cannot be reasonably probed.

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

Add a new <ioapic> element with a driver attribute.

Possible values are qemu and kvm. With 'qemu', the I/O
APIC can be put in the userspace even for KVM domains.

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