qemu-char: report udp backend errors

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
qemu-socket: don't leak opts on error

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
doc: we use seabios, not bochs bios

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
arch_init: Fix format string by using RAM_ADDR_FMT

length is a ram_addr_t, so RAM_ADDR_FMT must be used instead of %ld.
This fixes a recently introduced regression for w64 builds.

Using RAM_ADDR_FMT also changes decimal output to sedecimal.
This is good here because length and block->length should both
use the same base in the error message.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1372359606-2759-1-git-send-email-sw@weilnetz.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
multiboot: Don't forget last mmap entry

When the BIOS returns ebx = 0, the current entry is still valid and
needs to be included in the Multiboot memory map.

Fixing this meant that using bx as the entry index doesn't work any
more because it's 0 on the last entry (and it was SeaBIOS-specific
anyway), so the whole loop had to change a bit and should be more
generic as a result (ebx can be an arbitrary continuation number now,
and the entry size returned by the BIOS is used instead of hard-coding
20 bytes).

Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-2-git-send-email-mail@kevin-wolf.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
multiboot: Calculate upper_mem in the ROM

The upper_mem field of the Multiboot information struct doesn't really
contain the RAM size - 1 MB like we used to calculate it, but only the
memory from 1 MB up to the first (upper) memory hole.

In order to correctly retrieve this information, the multiboot ROM now
looks at the mmap it creates anyway and tries to find the size of
contiguous usable memory from 1 MB.

Drop the multiboot.c definition of lower_mem and upper_mem because both
are queried at runtime now.

Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-3-git-send-email-mail@kevin-wolf.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
multiboot: Updated ROM binary

Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-4-git-send-email-mail@kevin-wolf.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
vl: convert -smp to qemu_opts_parse()

This also introduces a new suboption, "cpus=",
which is the default.  So after this patch,

 -smp n,sockets=y

is the same as

  -smp cpus=n,sockets=y

(with "cpu" being some generic thing, referring to
either cores, or threads, or sockets, as before).

We still don't validate relations between different
numbers, for example it is still possible to say

  -smp 1,sockets=10

and it will be accepted to mean sockets=1.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Message-id: 1372072012-30305-1-git-send-email-mjt@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
gtk: add support for surface conversion

Also use CAIRO_FORMAT_RGB24 unconditionally.  DisplaySurfaces will never
ever see 8bpp surfaces.  And using CAIRO_FORMAT_RGB16_565 for the 16bpp
case doesn't seem to be a good idea too.

<quote src="/usr/include/cairo/cairo.h">
 * @CAIRO_FORMAT_RGB16_565: This format value is deprecated. It has
 *   never been properly implemented in cairo and should not be used
 *   by applications. (since 1.2)
</quote>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1372150134-8590-1-git-send-email-kraxel@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
console: Hook QemuConsoles into qom tree

Put them named "console[$index]" below "/backend", so you can
list & inspect them via QMP.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1372150171-8707-1-git-send-email-kraxel@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Fix ID reuse after chardev-remove for qapi-based init

Commit 2c5f488 introduced qapi-based character device initialization
as a new code path in qemu_chr_new_from_opts().  Unfortunately, it
failed to store parameter opts in the new chardev.  Therefore,
qemu_chr_delete() doesn't delete it.  Even though the device is gone,
its options linger, and any attempt to create another one with the
same ID fails.

Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1372339512-28149-1-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
hmp: Make "info block" output more readable

HMP is meant for humans and you should notice it.

This changes the output format to use a bit more space to display the
information more readable and leaves out irrelevant information (e.g.
mention only that an image is encrypted, but not when it's not; display
I/O limits only if throttling is in effect; ...)

Before:

    (qemu) info block
    ide0-hd0: removable=0 io-status=ok file=/tmp/overlay.qcow2
    backing_file=/tmp/backing.img backing_file_depth=1 ro=0 drv=qcow2
    encrypted=1 bps=0 bps_rd=0 bps_wr=0 iops=1024 iops_rd=0 iops_wr=0
    ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok
    file=/home/kwolf/images/iso/Fedora-18-x86_64-Live-Desktop.iso ro=1
    drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0
    floppy0: removable=1 locked=0 tray-open=0 [not inserted]
    sd0: removable=1 locked=0 tray-open=0 [not inserted]

After:

    (qemu) info block
    ide0-hd0: /tmp/overlay.qcow2 (qcow2, encrypted)
        Backing file:     /tmp/backing.img (chain depth: 1)
        I/O limits:       bps=0 bps_rd=0 bps_wr=0 iops=1024 iops_rd=0 iops_wr=0

    ide1-cd0: /home/kwolf/images/iso/Fedora-18-x86_64-Live-Desktop.iso (raw, read-only)
        Removable device: not locked, tray closed

    floppy0: [not inserted]
        Removable device: not locked, tray closed

    sd0: [not inserted]
        Removable device: not locked, tray closed

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Merge remote-tracking branch 'mjt/trivial-patches' into staging

# By Gerd Hoffmann (13) and Michael Tokarev (1)
# Via Michael Tokarev
* mjt/trivial-patches:
  doc: we use seabios, not bochs bios
  qemu-socket: don't leak opts on error
  qemu-char: report udp backend errors
  qemu-char: add -chardev mux support
  qemu-char: minor mux chardev fixes
  qemu-char: use ChardevBackendKind in CharDriver
  qemu-char: don't leak opts on error
  qemu-char: fix documentation for telnet+wait socket flags
  qemu-char: print notification to stderr
  qemu-char: use more specific error_setg_* variants
  qemu-char: check optional fields using has_*
  qemu-socket: catch monitor_get_fd failures
  qemu-socket: drop pointless allocation
  qemu-socket: zero-initialize SocketAddress

Message-id: 1372443465-22384-1-git-send-email-mjt@msgid.tls.msk.ru
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
KVM: Don't assume that mpstate exists with in-kernel PIC always

On PPC, we don't support MP state. So far it's not necessary and I'm
not convinced yet that we really need to support it ever.

However, the current idle logic in QEMU assumes that an in-kernel PIC
also means we support MP state. This assumption is not true anymore.

Let's split up the two cases into two different variables. That way
PPC can expose an in-kernel PIC, while not implementing MP state.

Signed-off-by: Alexander Graf <agraf@suse.de>
CC: Jan Kiszka <jan.kiszka@siemens.com>
KVM: Export kvm_init_irq_routing

On PPC, we can have different types of interrupt controllers, so we really
only know that we are going to use one when we created it.

Export kvm_init_irq_routing() to common code, so that we don't have to call
kvm_irqchip_create().

Signed-off-by: Alexander Graf <agraf@suse.de>
KVM: MSI: Swap payload to native endianness

The usual MSI injection mechanism writes msi.data into memory using an
le32 wrapper. So on big endian guests, this swaps msg.data into the
expected byte order.

For irqfd however, we don't swap the payload right now, rendering
in-kernel MPIC emulation broken on PowerPC.

Swap msg.data to the correct endianness whenever we touch it.

Signed-off-by: Alexander Graf <agraf@suse.de>
openpic: factor out some common defines into openpic.h

...for use by the KVM in-kernel irqchip stub.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: e500: factor out mpic init code

KVM in-kernel MPIC support is going to expand this even more,
so let's keep it contained.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
KVM: PIC: Only commit irq routing when necessary

The current logic updates KVM's view of our interrupt map every time we
change it. While this is nice and bullet proof, it slows things down
badly for me. QEMU spends about 3 seconds on every start telling KVM what
news it has on its routing maps.

Instead, let's just synchronize the whole irq routing map as a whole when
we're done constructing it. For things that change during runtime, we can
still update the routing table on demand.

Signed-off-by: Alexander Graf <agraf@suse.de>
PPC: Add non-kvm stub file

There are cases where a kvm provided function is called from generic
hw code that doesn't know whether kvm is available or not. Provide
a stub file which can provide simple replacement functions for those
cases.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>