w32, w64: Add build rule for installer

The new rules in Makefile allow building installers for QEMU on Windows
using NSIS, a package which is also available for Linux distributions
(so cross builds are possible).

The rules for NSIS are in qemu.nsi which also uses two new images.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
s390/IPL: Allow boot from other ssid than 0

We now take the subchannel set id also into account to find the boot device.
If we want to use a subchannel set other than the default set 0, we first
need to enable the mss facility.

Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
s390/ipl: Fix boot order

The latest ipl code adaptions collided with some of the virtio
refactoring rework. This resulted in always booting the first
disk. Let's fix booting from a given ID.
The new code also checks for command lines without bootindex to
avoid random behaviour when accessing dev_st (==0).

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
s390: update s390-ccw.img

This enables the following patches:

  s390/IPL: Allow boot from other ssid than 0
  s390/ipl: Fix spurious errors in virtio

Signed-off-by: Alexander Graf <agraf@suse.de>
xen_disk: support "direct-io-safe" backend option

Support backend option "direct-io-safe".  This is documented as
follows in the Xen backend specification:

 * direct-io-safe
 *      Values:         0/1 (boolean)
 *      Default Value:  0
 *
 *      The underlying storage is not affected by the direct IO memory
 *      lifetime bug.  See:
 *        http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
 *
 *      Therefore this option gives the backend permission to use
 *      O_DIRECT, notwithstanding that bug.
 *
 *      That is, if this option is enabled, use of O_DIRECT is safe,
 *      in circumstances where we would normally have avoided it as a
 *      workaround for that bug.  This option is not relevant for all
 *      backends, and even not necessarily supported for those for
 *      which it is relevant.  A backend which knows that it is not
 *      affected by the bug can ignore this option.
 *
 *      This option doesn't require a backend to use O_DIRECT, so it
 *      should not be used to try to control the caching behaviour.

Also, BDRV_O_NATIVE_AIO is ignored if BDRV_O_NOCACHE, so clarify the
default flags passed to the qemu block layer.

The original proposal for a "cache" backend option has been dropped
because it was believed too wide, especially considering that at the
moment the backend doesn't have a way to tell the toolstack that it is
capable of supporting it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Xen PV Device

Introduces a new Xen PV PCI device which will act as a binding point for
PV drivers for Xen.
The device has parameterized vendor-id, device-id and revision to allow to
be configured as a binding point for any vendor's PV drivers.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Merge remote-tracking branch 'sweil/w32' into staging

# By Stefan Weil (10) and others
# Via Aurelien Jarno (1) and Stefan Weil (1)
* sweil/w32: (27 commits)
  w32, w64: Add build rule for installer
  target-mips: fix mipsdsp_mul_q31_q31
  mips_malta: fix copy of the 0x1fc00000 region
  linux-user: correct argument number for sys_mremap and sys_splice
  target-mips: Remove assignment to a variable which is never used
  target-mips: fix mipsdsp_trunc16_sat16_round
  hw/mips: align initrd to 64KB to avoid kernel error
  pflash_cfi01: duplicate status byte from bits 23:16 for 32bit reads
  mips_malta: generate SMBUS EEPROM data
  mips_malta: cap BIOS endian swap length at 0x3e0000 bytes
  mips_malta: generate SPD EEPROM data at runtime
  mips_malta: correct reading MIPS revision at 0x1fc00010
  mips_malta: fix BIOS endianness swapping
  mips_malta: QOM cast cleanup
  target-mips: fix branch in likely delay slot tcg assert
  target-mips: fix multiplication in mipsdsp_rndq15_mul_q15_q15
  target-mips: Remove assignment to a variable which is never used
  misc: Use g_assert_not_reached for code which is expected to be unreachable
  qemu-options: mention C-a h in the -nographic doc
  misc: Fix new typos in comments and strings
  ...

Message-id: 1374989579-24933-1-git-send-email-sw@weilnetz.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Merge remote-tracking branch 'agraf/s390-for-upstream' into staging

# By Alexander Graf (1) and others
# Via Alexander Graf
* agraf/s390-for-upstream:
  s390: update s390-ccw.img
  s390/ipl: Fix boot order
  s390/IPL: Allow boot from other ssid than 0

Message-id: 1375092324-23943-1-git-send-email-agraf@suse.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Merge remote-tracking branch 'sstabellini/xen-130729' into staging

# By Paul Durrant (1) and Stefano Stabellini (1)
# Via Stefano Stabellini
* sstabellini/xen-130729:
  Xen PV Device
  xen_disk: support "direct-io-safe" backend option

Message-id: 1375096790-12815-1-git-send-email-stefano.stabellini@eu.citrix.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
cpu: Partially revert "cpu: Change qemu_init_vcpu() argument to CPUState"

Commit c643bed99 moved qemu_init_vcpu() calls to common CPUState code.
This causes x86 cpu-add to fail with "KVM: setting VAPIC address failed".

The reason for the failure is that CPUClass::kvm_fd is not yet
initialized in the following call graph:
->x86_cpu_realizefn
 ->x86_cpu_apic_realize
  ->qdev_init
   ->device_set_realized
    ->device_reset (hotplugged == 1)
     ->apic_reset_common
      ->vapic_base_update
       ->kvm_apic_vapic_base_update
This causes attempted KVM vCPU ioctls to fail.

By contrast, in the non-hotplug case the APIC is reset much later, when
the vCPU is already initialized.

As a quick and safe solution, move the qemu_init_vcpu() call back into
the targets' realize functions.

Reported-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Acked-by: Igor Mammedov <imammedo@redhat.com> (for i386)
Tested-by: Jia Liu <proljc@gmail.com> (for openrisc)
Signed-off-by: Andreas Färber <afaerber@suse.de>
target-i386: Pass X86CPU object to cpu_x86_find_by_name()

This will help us change the initialization code to not require carrying
some intermediate values in a x86_def_t struct (and eventually kill the
x86_def_t struct entirely).

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
target-i386: Disable PMU CPUID leaf by default

Bug description: QEMU currently gets all bits from GET_SUPPORTED_CPUID
for CPUID leaf 0xA and passes them directly to the guest. This makes
the guest ABI depend on host kernel and host CPU capabilities, and
breaks live migration if we migrate between hosts with different
capabilities (e.g., different number of PMU counters).

Add a "pmu" property to X86CPU, and set it to true only on "-cpu host",
or on pc-*-1.5 and older machine-types.

For now, setting pmu=on will enable the current passthrough mode that
doesn't have any ABI stability guarantees, but in the future we may
implement a mode where the PMU CPUID bits are stable and configurable.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
gluster: Add image resize support

Implement .bdrv_truncate in GlusterFS block driver so that GlusterFS backend
can support image resizing.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Tested-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
block: Repair the throttling code.

The throttling code was segfaulting since commit
02ffb504485f0920cfc75a0982a602f824a9a4f4 because some qemu_co_queue_next caller
does not run in a coroutine.
qemu_co_queue_do_restart assume that the caller is a coroutinne.
As suggested by Stefan fix this by entering the coroutine directly.
Also make sure like suggested that qemu_co_queue_next() and
qemu_co_queue_restart_all() can be called only in coroutines.

Signed-off-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
migration: notify migration state before starting thread

The migration thread runs outside the QEMU global mutex when possible.
Therefore we must notify migration state change *before* starting the
migration thread.

This allows registered listeners to act before live migration iterations
begin.  Therefore they can get into a state that allows for live
migration.  When the migration thread starts everything will be ready.

Without this patch there is a race condition during migration setup,
depending on whether the migration thread has already transitioned from
SETUP to ACTIVE state.

Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
migration: fix spice migration

Commit 29ae8a4133082e16970c9d4be09f4b6a15034617 ("rdma: introduce
MIG_STATE_NONE and change MIG_STATE_SETUP state transition") changed the
state transitions during migration setup.

Spice used to be notified with MIG_STATE_ACTIVE and it detected this
using migration_is_active().  Spice is now notified with
MIG_STATE_SETUP and migration_is_active() no longer works.

Replace migration_is_active() with migration_in_setup() to fix spice
migration.

Cc: Michael R. Hines <mrhines@us.ibm.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
dataplane: enable virtio-blk x-data-plane=on live migration

Although the dataplane thread does not cooperate with dirty memory
logging yet it's fairly easy to temporarily disable dataplane during
live migration.  This way virtio-blk can live migrate when
x-data-plane=on.

The dataplane thread will restart after migration is cancelled or if the
guest resuming virtio-blk operation after migration completes.

Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
dataplane: refuse to start if device is already in use

Dataplane must check whether a block device is in use before launching
the dataplane thread.  This is necessary since the thread does not
synchronize with the main loop and I/O requests could cause corruption.

One example is when a drive is added and a block job is started before
hotplugging the virtio-blk-pci adapter.  In this case we must not use
dataplane mode.

Cc: qemu-stable@nongnu.org
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
target-ppc: Convert ppc cpu savevm to VMStateDescription

The savevm code for the powerpc cpu emulation is currently based around
the old register_savevm() rather than register_vmstate() method.  It's also
rather broken, missing some important state on some CPU models.

This patch completely rewrites the savevm for target-ppc, using the new
VMStateDescription approach.  Exactly what needs to be saved in what
configurations has been more carefully examined, too.  This introduces a
new version (5) of the cpu save format.  The old load function is retained
to support version 4 images.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-id: 1374175984-8930-2-git-send-email-aliguori@us.ibm.com
[aik: ppc cpu savevm convertion fixed to use PowerPCCPU instead of CPUPPCState]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
pseries: savevm support for VIO devices

This patch adds helpers to allow PAPR VIO devices to save state common
to all VIO devices during savevm.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1374175984-8930-3-git-send-email-aliguori@us.ibm.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>