We find snapshots by iterating over the list of drives defined with
drive_init().  This misses host block devices defined by other means.
Such means don't exist now, but will be introduced later in this
series.

Iterate over all host block devices instead, with bdrv_next().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

This is a more flexible alternative to bdrv_iterate().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

do_commit() and mux_proc_byte() iterate over the list of drives
defined with drive_init().  This misses host block devices defined by
other means.  Such means don't exist now, but will be introduced later
in this series.

Change them to use new bdrv_commit_all(), which iterates over all host
block devices.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

That's where they belong semantically (block device host part), even
though the actions are actually executed by guest device code.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Use bdrv_pwrite to access the backing device instead of pread, and
convert the driver to implementing the bdrv_open method which gives
it an already opened BlockDriverState for the underlying device.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

We don't have an equivalent to mmap in the qemu block API, so read and
write the bitmap directly.  At least in the dumb implementation added
in this patch this is a lot less efficient, but it means cow can also
work on windows, and over nbd or curl.  And it fixes qemu-iotests testcase
012 which did not work properly due to issues with read-only mmap access.

In addition we can also get rid of the now unused get_mmap_addr function.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Use pread/pwrite instead of lseek + read/write in preparation of using the
qemu block API.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

If writing the L1 table to disk failed, we need to restore its old content in
memory to avoid inconsistencies.
Reported-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Empty file used to create an empty drive (no media).  Since commit
9dfd7c7a, it's an error: "qemu: could not open disk image : No such
file or directory".  Older versions of libvirt can choke on this.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.

First issue: Their names implies different porpouses, but they do the same thing
and have exactly the same code. Maybe copied and pasted and forgotten?
bdrv_has_snapshot() is called in various places for actually checking if there
is snapshots or not.

Second issue: the way bdrv_can_snapshot() verifies if a block driver supports or
not snapshots does not catch all cases. E.g.: a raw image.

So when do_savevm() is called, first thing it does is to set a global
BlockDriverState to save the VM memory state calling get_bs_snapshots().

static BlockDriverState *get_bs_snapshots(void)
{
    BlockDriverState *bs;
    DriveInfo *dinfo;

    if (bs_snapshots)
        return bs_snapshots;
    QTAILQ_FOREACH(dinfo, &drives, next) {
        bs = dinfo->bdrv;
        if (bdrv_can_snapshot(bs))
            goto ok;
    }
    return NULL;
 ok:
    bs_snapshots = bs;
    return bs;
}

bdrv_can_snapshot() may return a BlockDriverState that does not support
snapshots and do_savevm() goes on.

Later on in do_savevm(), we find:

    QTAILQ_FOREACH(dinfo, &drives, next) {
        bs1 = dinfo->bdrv;
        if (bdrv_has_snapshot(bs1)) {
            /* Write VM state size only to the image that contains the state */
            sn->vm_state_size = (bs == bs1 ? vm_state_size : 0);
            ret = bdrv_snapshot_create(bs1, sn);
            if (ret < 0) {
                monitor_printf(mon, "Error while creating snapshot on '%s'\n",
                               bdrv_get_device_name(bs1));
            }
        }
    }

bdrv_has_snapshot(bs1) is not checking if the device does support or has
snapshots as explained above. Only in bdrv_snapshot_create() the device is
actually checked for snapshot support.

So, in cases where the first device supports snapshots, and the second does not,
the snapshot on the first will happen anyways. I believe this is not a good
behavior. It should be an all or nothing process.

This patch addresses these issues by making bdrv_can_snapshot() actually do
what it must do and enforces better tests to avoid errors in the middle of
do_savevm(). bdrv_has_snapshot() is removed and replaced by bdrv_can_snapshot()
where appropriate.

bdrv_can_snapshot() was moved from savevm.c to block.c. It makes more sense to me.

The loadvm_state() function was updated too to enforce that when loading a VM at
least all writable devices must support snapshots too.
Signed-off-by: NMiguel Di Ciurcio Filho <miguel.filho@gmail.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

This fixes load_refcount_block which completely ignored the return value of
write_refcount_block and always returned -EIO for bdrv_pwrite failure.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Currently it would consider blocks for which get_refcount fails used. However,
it's unlikely that get_refcount would succeed for the next cluster, so it's not
really helpful. Return an error instead.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

get_refcount might need to load a refcount block from disk, so errors may
happen. Return the error code instead of assuming a refcount of 1 and change
the callers to respect error return values.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

This changes the vpc block driver (for VHD) to read/write multiple sectors at
once instead of doing a request for each single sector.

Before this, running qemu-iotests for VPC took ages, now it's actually quite
reasonable to run it always (down from ~1 hour to 40 seconds for me).
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Hook up any cleanup work which needs to be done here.  Advantages over
using atexit(3):

  (1) You get passed in a pointer to the notifier.  If you embed that
      into your state struct you can use container_of() to get get your
      state info.
  (2) You can unregister, say when un-plugging a device.

[ v2: move code out of #ifndef _WIN32 ]
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

PCI hotplug currently doesn't work after a migration because
we don't migrate the enable bits of the GPE state.  Pull hotplug
structs into vmstate.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Restrict IDs to letters, digits, '-', '.', '_', starting with a
letter.

This takes care of '/' in qdev IDs breaking qbus_find().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Setting the ID in pci_nic_init() is a blatant violation of the
DeviceState abstraction.  Which even carries a comment advising
against this:

/* This structure should not be accessed directly.  We declare it here
   so that it can be embedded in individual device state structures.  */

What's worse, it bypasses the code ensuring unique qdev IDs: "-device
virtio-net-pci,id=foo -net nic,id=foo -net nic,name=foo" happily
creates three qdevs with ID "foo".  That's because qdev relies on
qemu_opts_create() to ensure unique IDs, but -net nic uses a different
QemuOptsList, which means id is in a different namespace.  And its
name is not checked for uniqueness at all.

-net nic and pci_add are legacy.  Use -device and device_add if you
want a NIC with a qdev ID.

This reverts what's still left of commit eb54b6dc "qdev: add id=
support for pci nics."
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:

$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not available for virtio-balloon-pci, in use by rtl8139

The user does not configure 'devfn' numbers, they use slot+function.
Thus the error messages should be reported back to the user with that
same terminology rather than the internal QEMU terminology. This
patch makes it report:

$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu: -device virtio-balloon-pci,bus=pci.0,addr=0x3.7: PCI: slot 3 function 0 not available for virtio-balloon-pci, in use by rtl8139
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Pass the MultiReqBuffer structure down all the way to the I/O submission
instead of takin it apart.  Also mark num_writes unsigned as it can't
go negative, and take the check for any pending I/O requests into the
submission function.  Last but not least rename do_multiwrite to
virtio_submit_multiwrite to fit the general naming scheme and make clear
what it does.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

There is a 1:1 relation between VirtIOBlock and BlockDriverState instances,
no need to track it because it won't change.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If a USB keyboard is unplugged, the keyboard eventhandler is never
removed, and events will continue to be passed through to the device,
causing crashes or memory corruption.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

All signals will thus be routed through the IO thread.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This patch fixes the following error report.  When changing
migration-tcp.c to call migrate_fd_error() instead of close() and
free() by itself, monitor is resumed, and returns allocated mig_state
is set to current_migration in migration.c allows us to print "info
migrate".
Reported-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NYoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Although there is no difference, other migration related code use
qemu_free(), and it should be better to be consistent.
Signed-off-by: NYoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Add support for the rx fifo to speed up bulk transfers.
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@axis.com>

This makes the RAM block list easier to manipulate.  Also incorporate
relevant variables into the RAMList struct.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NChris Wright <chrisw@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

To hot-unplug guest and host part of a network device, you do:

    device_del NIC-ID
    netdev_del NETDEV-ID

For PCI devices, device_del merely tells ACPI to unplug the device.
The device goes away for real only after the guest processed the ACPI
unplug event.

You have to wait until then (e.g. by polling info pci) before you can
unplug the netdev.  Not good.

Fix by removing the "in use" check from do_netdev_del().  Deleting a
netdev while it's in use is safe; packets simply get routed to the bit
bucket.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios no longer uses hard coded hpet configuration. Proposed
interface supports up to 8 hpets. This is the number defined by hpet
spec.
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The capability register is read-only from guest POV, so we do not need
to update it on reset.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When dest is NULL, i.e. a new copy of the list is created, we don't get a
properly terminated list after the realloc. Initialize it as an empty list.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Change #define DEBUG to #define E1000_DEBUG in hw/e1000.c to make
it possible to build QEMU with -DDEBUG
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Remove unused DEBUG defines from hw/msix.c to avoid having anything
define the word DEBUG without any additions such as MSIX_DEBUG.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Conflicts:
	hw/pc.c

Ignore high address bits when PCI memory window is not mapped on a page
boundary.
Signed-off-by: NPaul Brook <paul@codesourcery.com>

Move inclusion of stdbool.h to common header files, instead of including
in an ad-hoc manner.
Signed-off-by: NPaul Brook <paul@codesourcery.com>

This command was of minimal use before, now it is useless as the hpet
become a qdev device and is thus easily discoverable. We should
definitely not set query-hpet in QMP's stone, and there is also no good
reason to keep it for the interactive monitor.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This implements the HPET capability of routing IRQs to the front-side
bus, aka MSI support. This feature can be enabled via the qdev property
"msi" and is off by default.

Note that switching it on can cause guests (at least Linux) to use the
HPET as timer instead of the LAPIC. KVM users should recall that only
the latter is currently available as fast in-kernel model.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>