slirp: Clean up ifs_init

Remove duplicate ifs_init macros, reimplement the logic as static inline
in mbuf.h.

CC: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
CC: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Disable hpet for unaccelerated qemu

Hpet is not really needed for unaccelerated qemu, and currently causes it
to hang on boot.  The bug is fixed upstream, but the fix is not cleanly
cherrypick-able, so simply "don't do that".

Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668186
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/qemu-kvm/+bug/975240

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
rbd: always set out parameter in qemu_rbd_snap_list

The caller expects psn_tab to be NULL when there are no snapshots or
an error occurs. This results in calling g_free on an invalid address.

Reported-by: Oliver Francke <Oliver@filoo.de>
Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
rbd: wire up snapshot removal and rollback functionality

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
When migrating a vm using vhost-net we hit the following assertion:

qemu-kvm: /usr/src/packages/BUILD/qemu-kvm-0.15.1/hw/vhost.c:30:
vhost_dev_sync_region: Assertion `start / (0x1000 * (8 *
sizeof(vhost_log_chunk_t))) < dev->log_size' failed.

The cases which the end < start check is intended to catch, such as
for vga video memory, will also likely trigger the assertion.
Reorder the code to handle this correctly.

Signed-off-by: Bruce Rogers <address@hidden>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
keep the PID file locked for the lifetime of the process

The lockf() call in qemu_create_pidfile() aims at ensuring mutual
exclusion. We shouldn't close the pidfile on success (as introduced by
commit 1bbd1592), because that drops the lock as well [1]:

    "File locks shall be released on first close by the locking process
    of any file descriptor for the file."

Coverity may complain again about the leaked file descriptor; let's
worry about that later.

v1->v2:
- add reference to 1bbd1592
- explain the intentional fd leak in the source

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.html

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
fix file overwrite via incorrect temp file checking (CVE-2012-2652)

Origin: upstream, http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=eba25057b9a5e19d10ace2bc7716667a31297169
Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=824919
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678280

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
virtio: add missing mb() on notification

During normal operation, virtio first writes a used index
and then checks whether it should interrupt the guest
by reading guest avail index/flag values.

Guest does the reverse: writes the index/flag,
then checks the used ring.

The ordering is important: if host avail flag read bypasses the used
index write, we could in effect get this timing:

host avail flag read
		guest enable interrupts: avail flag write
		guest check used ring: ring is empty
host used index write

which results in a lost interrupt: guest will never be notified
about the used ring update.

This actually can happen when using kvm with an io thread,
such that the guest vcpu and qemu run on different host cpus,
and this has actually been observed in the field
(but only seems to trigger on very specific processor types)
with userspace virtio: vhost has the necessary smp_mb()
in place to prevent the regordering, so the same workload stalls
forever waiting for an interrupt with vhost=off but works
fine with vhost=on.

Insert an smp_mb barrier operation in userspace virtio to
ensure the correct ordering.
Applying this patch fixed the race condition we have observed.
Tested on x86_64. I checked the code generated by the new macro
for i386 and ppc but didn't run virtio.

Note: mb could in theory be implemented by __sync_synchronize, but this
would make us hit old GCC bugs. Besides old GCC
not implementing __sync_synchronize at all, there were bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
in this functionality as recently as in 4.3.

As we need asm for rmb,wmb anyway, it's just as well to
use it for mb.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio: add missing mb() on enable notification

This fixes an issue dual to the one fixed by
patch 'virtio: add missing mb() on notification'
and applies on top.

In this case, to enable vq kick to exit to host,
qemu writes out used flag then reads the
avail index. if these are reordered we get a race:

    host avail index read: ring is empty
    		guest avail index write
    		guest flag read: exit disabled
    host used flag write: enable exit

which results in a lost exit: host will never be notified about the
avail index update.  Again, happens in the field but only seems to
trigger on some specific hardware.

Insert an smp_mb barrier operation to ensure the correct ordering.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio: order index/descriptor reads

virtio has the equivalent of:

	if (vq->last_avail_index != vring_avail_idx(vq)) {
		read descriptor head at vq->last_avail_index;
	}

In theory, processor can reorder descriptor head
read to happen speculatively before the index read.
this would trigger the following race:

	host descriptor head read <- reads invalid head from ring
		guest writes valid descriptor head
		guest writes avail index
	host avail index read <- observes valid index

as a result host will use an invalid head value.
This was not observed in the field by me but after
the experience with the previous two races
I think it is prudent to address this theoretical race condition.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
fix privilege escalation via VT100 sequences (CVE-2012-3515)

Origin: upstream, http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=3eea5498ca501922520b3447ba94815bfc109743
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686764

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
nbd: fixes to read-only handling

We do not need BLKROSET if the kernel supports setting flags.
Also, always do BLKROSET even for a read-write export, otherwise
the read-only state remains "sticky" after the invocation of
"qemu-nbd -r".

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
guest denial of service and possible code execution via e1000 large packets (CVE-2012-6075)

Origin: upstream, http://git.qemu.org/?p=qemu.git;a=commit;h=b0d9ffcd0251161c7c92f94804dcf599dfa3edeb
Origin: upstream, http://git.qemu.org/?p=qemu.git;a=commit;h=2c0331f4f7d241995452b99afaf0aab00493334a
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696051

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
hw/9pfs: Remove O_NOATIME flag from 9pfs open() calls in readonly mode

When 2c74c2cb4bedddbfa67628fbd5f9273b4e0e9903 added support for
the 'readonly' flag against 9p filesystems, it also made QEMU
add the O_NOATIME flag as a side-effect.

The O_NOATIME flag, however, may only be set by the file owner,
or a user with CAP_FOWNER capability.  QEMU cannot assume that
this is the case for filesytems exported to QEMU.

eg, run QEMU as non-root, and attempt to pass the host OS
filesystem through to the guest OS with readonly enable.
The result is that the guest OS cannot open any files at
all.

If O_NOATIME is really required, it should be optionally
enabled via a separate QEMU command line flag.

* hw/9pfs/virtio-9p.c: Remove O_NOATIME

Acked-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
qcow2: start at 0 when counting cow clusters

BugLink: http://bugs.launchpad.net/bugs/1189926

This patch fixes corruption issues.
While searching for available clusters, if we detect an ongoing AIO
write request, then we restart after the other has completed. By not
re-setting i to 0, we fail to re-check clusters which may no longer be
available.

Signed-off-by: Chris J Arges <chris.j.arges@ubuntu.com>