The collision reports before and after this patch are:

before:

warning: subregion collision cfc/4 (pci-conf-data) vs cf8/4 (pci-conf-idx)
warning: subregion collision 8000000/f8000000 (pci-hole) vs 0/8000000 (ram-below-4g)
warning: subregion collision 100000000/4000000000000000 (pci-hole64) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 4d1/1 (kvm-elcr) vs 4d0/1 (kvm-elcr)
warning: subregion collision fec00000/1000 (kvm-ioapic) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 80/1 (ioport80) vs 7e/2 (kvmvapic)
warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 81/3 (dma-page) vs 80/1 (ioport80)
warning: subregion collision 8/8 (dma-cont) vs 0/8 (dma-chan)
warning: subregion collision d0/10 (dma-cont) vs c0/10 (dma-chan)
warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont)
warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan)
warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd)
warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data)
warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr)
warning: subregion collision 0/80 (ich9-pm) vs 40/4 (kvm-pit)
warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc)
warning: subregion collision 0/80 (ich9-pm) vs 20/2 (kvm-pic)
warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic)
warning: subregion collision 4/2 (acpi-cnt) vs 0/4 (acpi-evt)
warning: subregion collision 30/8 (apci-smi) vs 20/10 (apci-gpe0)
warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs 8000000/f8000000 (pci-hole)

after:

warning: subregion collision fec00000/1000 (kvm-ioapic) vs 8000000/f8000000 (pci-hole)
warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont)
warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan)
warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd)
warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data)
warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr)
warning: subregion collision 0/80 (ich9-pm) vs 40/4 (kvm-pit)
warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc)
warning: subregion collision 0/80 (ich9-pm) vs 20/2 (kvm-pic)
warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic)
warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs 8000000/f8000000 (pci-hole)
Signed-off-by: NHu Tao <hutao@cn.fujitsu.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Instead of adding missing type casts which are needed by MinGW for the
4th argument, the patch uses qemu_setsockopt which was invented for this
purpose.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

# By Gerd Hoffmann
# Via Gerd Hoffmann
* kraxel/ipxe.2:
  Switch to efi-enabled nic roms by default
  Add efi rom binaries
  Add Makefile rules to build nic rom binaries with efi support
  Update ipxe submodule to latest master
  Add Makefile rules to build nic rom binaries

Seabios already added a new device type to halt booting.
Qemu can add "HALT" at the end of bootindex string, then
seabios will halt booting after trying to boot from all
selected devices.

This patch added a new boot option to configure if boot
from un-selected devices.

This option only effects when boot priority is changed by
bootindex options, the old style(-boot order=..) will still
try to boot from un-selected devices.

v2: add HALT entry in get_boot_devices_list()
v3: rebase to latest qemu upstream
Signed-off-by: NAmos Kong <akong@redhat.com>
Message-id: 1363674207-31496-1-git-send-email-akong@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Fix various compilation failures introduced by the recent console
changes.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363638501-29603-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

# By Stefan Hajnoczi (2) and others
# Via Kevin Wolf
* kwolf/for-anthony:
  virtio-blk: Do not segfault fault if failed to initialize dataplane
  qemu-iotests: add 052 BDRV_O_SNAPSHOT test
  block: fix BDRV_O_SNAPSHOT protocol detection
  qcow2: Fix segfault in qcow2_invalidate_cache
  sheepdog: show error message for halt status

qemu_chr_fe_add_watch() can return negative errors, therefore it must
not have an unsigned return type. For consistency with other
qemu_chr_fe_* functions, this uses a standard C int instead of glib
types.

In situations where qemu_chr_fe_add_watch() is falsely assumed to have
succeeded, the serial ports would go into a state where it never becomes
ready for transmitting more data; this is fixed by this patch.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

chardev flow control broke monitor, fix it by adding watch support.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -drive if=none,id=drive0,cache=none,aio=native,format=raw,file=/root/Image/centos-6.4.raw -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on # make dataplane fail to initialize
qemu-system-x86_64: -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on: device is incompatible with x-data-plane, use config-wce=off
*** glibc detected *** /root/usr/bin/qemu-system-x86_64: free(): invalid pointer: 0x00007f001fef12f8 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7d776)[0x7f00153a5776]
/root/usr/bin/qemu-system-x86_64(+0x2c34ec)[0x7f001cf5b4ec]
/root/usr/bin/qemu-system-x86_64(+0x342f9a)[0x7f001cfdaf9a]
/root/usr/bin/qemu-system-x86_64(+0x33694e)[0x7f001cfce94e]
....................

 (gdb) bt
 #0  0x00007f3bf3a12015 in raise () from /lib64/libc.so.6
 #1  0x00007f3bf3a1348b in abort () from /lib64/libc.so.6
 #2  0x00007f3bf3a51a4e in __libc_message () from /lib64/libc.so.6
 #3  0x00007f3bf3a57776 in malloc_printerr () from /lib64/libc.so.6
 #4  0x00007f3bfb60d4ec in free_and_trace (mem=0x7f3bfe0129f8) at vl.c:2786
 #5  0x00007f3bfb68cf9a in virtio_cleanup (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:900
 #6  0x00007f3bfb68094e in virtio_blk_device_init (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio-blk.c:666
 #7  0x00007f3bfb68dadf in virtio_device_init (qdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:1092
 #8  0x00007f3bfb50da46 in device_realize (dev=0x7f3bfe0129f8, err=0x7fff479c9258) at hw/qdev.c:176
.............................

In virtio_blk_device_init(), the memory which vdev point to is a static
member of "struct VirtIOBlkPCI", not heap memory, and it does not
get freed. So we shoule use virtio_common_cleanup() to clean this VirtIODevice
rather than virtio_cleanup(), which attempts to free the vdev.

This error was introduced by commit 05ff6865
recently.
Signed-off-by: NDunrong Huang <huangdr@cloud-times.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Check that writes to an image opened with BDRV_O_SNAPSHOT do not modify
the underlying image file.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

realpath(3) is used to get an absolute path to the image file when
creating a -drive snapshot=on temporary qcow2.  This does not work for
protocols since their filenames ("proto:foo:...") do not correspond to
file system paths.

Commit 7c96d46e ("Let snapshot work with
protocols") skipped realpath(3) for protocols.  Later on the "raw"
format was introduced and broke the check.

Use path_has_protocol(filename) to decide if this image uses a protocol
or a filename.
Reported-by: NRichard Jones <rjones@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Need to pass an options QDict to qcow2_open() now. This fixes a segfault
on the migration target with qcow2.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Sheepdog (neither quorum nor unsafe mode) will refuse to serve IO requests when
number of alive nodes is less than that of copies specified by users. This will
return 0x19 to QEMU client which currently doesn't recognize it.

This patch adds an error description when QEMU client receives it, other than
plainly printing 'Invalid error code'

Cc: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NLiu Yuan <tailai.ly@taobao.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

The qdev field is no longer needed, just drop it.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-12-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Use QOM casts inside virtio-blk.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-11-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

As all virtio-blk-* are switched to the new API, we can remove the separate
init/exit for the old API.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-10-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Here the virtio-ccw-s390 is modified for the new API. The device
virtio-ccw-s390 extends virtio-ccw-device as before. It creates and
connects a virtio-ccw during the init. The properties are not modified.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-9-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Here the virtio-blk-s390 is modified for the new API. The device
virtio-blk-s390 extends virtio-s390-device as before. It creates and
connects a virtio-blk during the init. The properties are not modified.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-8-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Here the virtio-blk-pci is modified for the new API. The device
virtio-blk-pci extends virtio-pci. It creates and connects a virtio-blk
during the init. The properties are not changed.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-7-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Create virtio-blk which extends virtio-device, so it can be connected on
virtio-bus.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-6-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The configuration field must not be a pointer as it will be used for virtio-blk
properties. So *blk is replaced by blk in VirtIOBlock structure.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1363624648-16906-5-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Hot unplug failed because it tried to free the virtio device two times.

This fix the issue by removing the call to virtio_bus_destroy_device.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Message-id: 1363624648-16906-4-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This set allow_hotplug for each existing virtio-x-bus, allowing the
refactored devices to be hot pluggable.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Message-id: 1363624648-16906-3-git-send-email-fred.konrad@greensocs.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

These structures must be made public to avoid two memory allocations for
refactored virtio devices.
Signed-off-by: NKONRAD Frederic <fred.konrad@greensocs.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1363624648-16906-2-git-send-email-fred.konrad@greensocs.com

Changes V4 <- V3:
   * Rebased on current git.

Changes V3 <- V2:
    * Style correction spotted by Andreas (virtio-scsi.h).
    * Style correction for virtio-net.h.

Changes V2 <- V1:
    * Move the dataplane include into the header (virtio-blk).
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

# By Gerd Hoffmann (18) and others
# Via Blue Swirl (1) and Gerd Hoffmann (1)
* kraxel/pixman.v8: (37 commits)
  console: remove ds_get_* helper functions
  console: zap color_table
  console: stop using DisplayState in gfx hardware emulation
  console: zap displaystate from dcl callbacks
  cocoa: stop using DisplayState
  spice: stop using DisplayState
  sdl: stop using DisplayState
  vnc: stop using DisplayState
  gtk: stop using DisplayState
  console: add surface_*() getters
  console: rework DisplaySurface handling [dcl/ui side]
  console: rework DisplaySurface handling [vga emu side]
  sdl: drop dead code
  qxl: better vga init in enter_vga_mode
  qxl: zap qxl0 global
  spice: zap sdpy global
  console: kill DisplayState->opaque
  console: fix displaychangelisteners interface
  s390: Fix cpu refactoring fallout.
  target-mips: fix rndrashift_short_acc and code for EXTR_ instructions
  ...

Switch the few remaining ds_get_* uses in console.c over to the new
surface_* accessors.

While doing so tripped over a few leftovers from commit
a93a4a22 (code using depth == 0
as indicator for textmode rendering).  Fixed them up.

Finally dropped ds_get_* helper helpers.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

qemu_create_surface hands out 32bpp surfaces.
So we can just use color_table_rgb directly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Use QemuConsole instead.  Updates interfaces in console.[ch] and adapts
gfx hardware emulation code.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Now that nobody depends on DisplayState in DisplayChangeListener
callbacks any more we can remove the parameter from all callbacks.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Rework DisplayStateListener callbacks to not use the DisplayState
any more.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Rework DisplayStateListener callbacks to not use the DisplayState
any more.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Rework DisplayStateListener callbacks to not use the DisplayState
any more.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Rework DisplayStateListener callbacks to not use the DisplayState
any more.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Rework DisplayStateListener callbacks to not use the DisplayState
any more.  Factor out the window size handling to a separate function,
so the zoom callbacks can call that directly instead of abusing the
gd_switch DisplayStateListener callback for that.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add convinence wrappers to query DisplaySurface properties.
Simliar to ds_get_*, but operating in the DisplaySurface
not the DisplayState.

With this patch in place ui frontents can stop using DisplayState
in the rendering code paths, they can simply operate using the
DisplaySurface passed in via dpy_gfx_switch callback.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Replace the dpy_gfx_resize and dpy_gfx_setdata DisplayChangeListener
callbacks with a dpy_gfx_switch callback which notifies the ui code
when the framebuffer backing storage changes.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Decouple DisplaySurface allocation & deallocation from DisplayState.
Replace dpy_gfx_resize + dpy_gfx_setdata with a dpy_gfx_replace_surface
function.

This handles the graphic hardware emulation.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

DisplayAllocator removal (commit
187cd1d9) made this a nop.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Ask the vga core to update the display.  Will trigger dpy_gfx_resize
if needed.  More complete than just calling dpy_gfx_resize.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>