The current behaviour of tap_open for BSD systems differ greatly from
it's Linux counterpart. Since FreeBSD supports interface renaming and
tap device cloning by opening /dev/tap, implement a FreeBSD specific
version of tap_open that behaves like it's Linux counterpart.

This is specially important for toolstacks that use Qemu (like Xen
libxl), in order to have a unified behaviour across suported
platforms.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>

ENODATA doesn't exist on FreeBSD, so ENODATA errors returned by the
hypervisor are translated to ENOENT.

Also, the error code is returned in errno if the call returns -1, so
compare the error code with the value in errno instead of the value
returned by the function.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

pl031's base address should be 0x9010000, not 0x90010000, otherwise
it sits in ram when configuring a guest with greater than 1G.
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Add new translations for recently added messages.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
Reviewed-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

pc migration fixes

Last minute fixes for migration.
It seems that if we don't fix it now, fixing
it in the next version will be even more painful ...
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Tue 29 Jul 2014 11:45:18 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"

* remotes/mst/tags/for_upstream:
  piix: set legacy table size for 1.7
  acpi-build: tweak acpi migration limits
  pc: future-proof migration-compatibility of ACPI tables
  acpi-build: minor code cleanup
  pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled
  bios-tables-test: fix ASL normalization false positive
  pc: hack for migration compatibility from QEMU 2.0
  acpi-dsdt: procedurally generate _PRT
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

- Tweak error message for legacy machine type:
  Basically if table size exceeds the limits we set all
  bets are off for migration: e.g. it can start failing even
  within given qemu minor version simply because of a bugfix.
- Increase table size to 128k.
- Make sure we notice it long before we start getting close to the
  128k limit: warn at 64k.
- Don't fail if we exceed the limit: most people don't care about
  migration, even less people care about cross version miration.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

This patch avoids that similar changes break QEMU again in the future.
QEMU will now hard-code 64k as the maximum ACPI table size, which
(despite being an order of magnitude smaller than 640k) should be enough
for everyone.
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Fix up and add  comments to clarify code, plus a trivial
code change for clarity.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Fixes migration regression from QEMU-1.7 to a newer QEMUs.
SSDT table size in QEMU-1.7 doesn't change regardless of
a number of PCI bridge devices present at startup.

However in QEMU-2.0 since addition of hotplug on PCI bridges,
each PCI bridge adds ~1875 bytes to SSDT table, including
pc-i440fx-1.7 machine type where PCI bridge hotplug disabled
via compat property.
It breaks migration from "QEMU-1.7" to "QEMU-2.[01] -M pc-i440fx-1.7"
since RAMBlock size of ACPI tables on target becomes larger
then on source and migration fails with:

"Length mismatch: /rom@etc/acpi/tables: 2000 in != 3000"

error.

Fix this by generating AML only for PCI0 bus if
hotplug on PCI bridges is disabled and preserves PCI brigde
description in AML as it was done in QEMU-1.7 for pc-i440fx-1.7.

It will help to maintain size of SSDT static regardless of
number of PCI bridges on startup for pc-i440fx-1.7 machine type.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

My version of IASL (from RHEL7) puts two newlines between the head comment
and the DefinitionBlock property.  Kill all newlines after the comment,
so that normalize_asl works properly.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>

Line numbers changed, and some translations were missing after commit
3d914488.

Update also "Show Tabs" to a more common translation, and remove some
old unused lines at the end.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Free t0 and t1 in opcode OPC_DINSV.
Signed-off-by: NDongxue Zhang <elta.era@gmail.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Changing the ACPI table size causes migration to break, and the memory
hotplug work opened our eyes on how horribly we were breaking things in
2.0 already.

The ACPI table size is rounded to the next 4k, which one would think
gives some headroom.  In practice this is not the case, because the user
can control the ACPI table size (each CPU adds 97 bytes to the SSDT and
8 to the MADT) and so some "-smp" values will break the 4k boundary and
fail to migrate.  Similarly, PCI bridges add ~1870 bytes to the SSDT.

This patch concerns itself with fixing migration from QEMU 2.0.  It
computes the payload size of QEMU 2.0 and always uses that one.
The previous patch shrunk the ACPI tables enough that the QEMU 2.0 size
should always be enough; non-AML tables can change depending on the
configuration (especially MADT, SRAT, HPET) but they remain the same
between QEMU 2.0 and 2.1, so we only compute our padding based on the
sizes of the SSDT and DSDT.

Migration from QEMU 1.7 should work for guests that have a number of CPUs
other than 12, 13, 14, 54, 55, 56, 97, 98, 139, 140.  It was already
broken from QEMU 1.7 to QEMU 2.0 in the same way, though.

Even with this patch, QEMU 1.7 and 2.0 have two different ideas of
"-M pc-i440fx-2.0" when there are PCI bridges.  Igor sent a patch to
adopt the QEMU 1.7 definition.  I think distributions should apply
it if they move directly from QEMU 1.7 to 2.1+ without ever packaging
version 2.0.
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This replaces the _PRT constant with a method that computes it.

The problem is that the DSDT+SSDT have grown from 2.0 to 2.1,
enough to cross the 8k barrier (we align the ACPI tables to 4k
before putting them in fw_cfg).  This causes problems with
migration and the pc-i440fx-2.0 machine type.

The solution to the problem is to hardcode 64k as the limit,
but this doesn't solve the bug with pc-i440fx-2.0.  The fix will be
for QEMU 2.1 to use exactly the same size as QEMU 2.0 for the
ACPI tables.  First, however, we must make the actual AML
equal or smaller; to do this, rewrite _PRT in a way that saves
over 1k of bytecode.
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

trivial patches for 2014-07-26

# gpg: Signature made Sat 26 Jul 2014 08:16:55 BST using RSA key ID A4C3D7DB
# gpg: Good signature from "Michael Tokarev <mjt@tls.msk.ru>"
# gpg:                 aka "Michael Tokarev <mjt@corpit.ru>"
# gpg:                 aka "Michael Tokarev <mjt@debian.org>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 8044 65C5
#      Subkey fingerprint: 6F67 E18E 7C91 C5B1 5514  66A7 BEE5 9D74 A4C3 D7DB

* remotes/mjt/tags/trivial-patches-2014-07-26:
  qemu-options: fix another allows-to for -net l2tpv3
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Here is the serial fix for 2.1.

# gpg: Signature made Fri 25 Jul 2014 13:36:23 BST using RSA key ID 9B4D86F2
# gpg: Good signature from "Paolo Bonzini <pbonzini@redhat.com>"
# gpg:                 aka "Paolo Bonzini <bonzini@gnu.org>"

* remotes/bonzini/tags/for-upstream:
  qemu-char: ignore flow control if a PTY's slave is not connected
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

After commit f702e62a (serial: change retry logic to avoid concurrency,
2014-07-11), guest boot hangs if the backend is an unconnected PTY.

The reason is that PTYs do not support G_IO_HUP, and serial_xmit is
never called.  To fix this, simply invoke serial_xmit immediately
(via g_idle_source_new) when this happens.
Tested-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

vnc: fix two vnc update issues.

# gpg: Signature made Fri 25 Jul 2014 08:44:23 BST using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"

* remotes/kraxel/tags/pull-vnc-20140725-1:
  vnc update fix
  fix full frame updates for VNC clients
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

We need to remember has_updates for each vnc client.  Otherwise it might
happen that vnc_update_client(has_dirty=1) takes the first exit due to
output buffers not being flushed yet and subsequent calls with
has_dirty=0 take the second exit, wrongly assuming there is nothing to
do because the work defered in the first call is ignored.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NPeter Lieven <pl@kamp.de>

If the client asks for !incremental frame updates, it has lost its content
so dirty doesn't matter - it has to see the full frame, so setting force_update
Signed-off-by: NStephan Kulow <coolo@suse.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NPeter Lieven <pl@kamp.de>

* remotes/qmp-unstable/queue/qmp:
  docs: document missing VSERPORT_CHANGE event
  docs: document missing POWERDOWN event
  docs: document missing SPICE_MIGRATE_COMPLETED event
  docs: split SPICE_* event docs
  docs: grammar fixes to qmp-events
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The VSERPORT_CHANGE event was added in e2ae6159.  The patch for
this event was prepared at a time when this file was gone, even
though it got applied immediately after dfab4892 restored this
file.  Duplicate the documentation into this file, so that
anyone using this file instead of qapi will not miss out on this
new event.

* docs/qmp/qmp-events.txt (VSERPORT_CHANGE): Add.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NWenchao Xia <wenchaoqemu@gmail.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

The POWERDOWN event was first documented in 0aab9ec3.  But since
dfab4892 later restored this file to the state prior to qmp events,
and we never documented it in the past, anyone using this file
instead of qapi will miss out on this event.  Tweak the existing
wording of SHUTDOWN to match 84321831, and make the difference
between the two events apparent.

* docs/qmp/qmp-events.txt (POWERDOWN): Add.
(SHUTDOWN): Tweak.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NWenchao Xia <wenchaoqemu@gmail.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

The SPICE_MIGRATE_COMPLETED event was first documented in
7cfadb6b.  But since dfab4892 later restored this file to the
state prior to qmp events, and we never documented it in the
past, anyone using this file instead of qapi will miss out on
this event.

* docs/qmp/qmp-events.txt (SPICE_MIGRATE_COMPLETED): Add.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NWenchao Xia <wenchaoqemu@gmail.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

For consistency with the rest of this file, every event should be
listed in isolation.  Compare how commit 7cfadb6b split
SPICE_CONNECTED and SPICE_DISCONNECTED into separate qmp events.

* docs/qmp/qmp-events.txt (SPICE_CONNECTED, SPICE_DISCONNECTED):
Split.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NWenchao Xia <wenchaoqemu@gmail.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

When converting to qmp events, commits 7cfadb6b and a6330785
fixed some grammar as part of moving text between files.  But
since dfab4892 later restored this file to the state prior to
qmp events, we have to do it again.

* docs/qmp/qmp-events.txt (RESET, SPICE_INITIALIZED): Tweak.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NWenchao Xia <wenchaoqemu@gmail.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

usb: mtp: tag root property as experimental

# gpg: Signature made Wed 23 Jul 2014 07:56:21 BST using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"

* remotes/kraxel/tags/pull-usb-20140723-1:
  usb: mtp: tag root property as experimental
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Reason: we don't want commit to that interface yet.  Possibly
the implementation will be switched over to use fsdev.
Suggested-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The VMStateDescription for the imx_ccm device was missing its
terminator. Found by static search of the codebase using
a regex based on one suggested by Ian Jackson:
  pcregrep -rMi '(?s)VMStateField(?:(?!END_OF_LIST).)*?;' $(git grep -l 'VMStateField\[\]')
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Cc: qemu-stable@nongnu.org

"vmstate_xhci_event" was introduced in commit 37352df3 ("xhci: add live
migration support"), and first released in v1.6.0. The field list in this
VMSD is not terminated with the VMSTATE_END_OF_LIST() macro.

During normal use (ie. migration), the issue is practically invisible,
because the "vmstate_xhci_event" object (with the unterminated field list)
is only ever referenced -- via "vmstate_xhci_intr" -- if xhci_er_full()
returns true, for the "ev_buffer" test. Since that field_exists() check
(apparently) almost always returns false, we almost never traverse
"vmstate_xhci_event" during migration, which hides the bug.

However, Amit's vmstate checker forces recursion into this VMSD as well,
and the lack of VMSTATE_END_OF_LIST() breaks the field list terminator
check (field->name != NULL) in dump_vmstate_vmsd(). The result is
undefined behavior, which in my case translates to infinite recursion
(because the loop happens to overflow into "vmstate_xhci_intr", which then
links back to "vmstate_xhci_event").

Add the missing terminator.
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Patch queue for ppc - 2014-07-22

Only a single bug fix to make -mem-path only affect RAM regions.

# gpg: Signature made Tue 22 Jul 2014 16:38:04 BST using RSA key ID 03FEDC60
# gpg: Can't check signature: public key not found

* remotes/agraf/tags/signed-ppc-for-upstream:
  ppc: fix -mem-path failure
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

commit e938ba0c tried to enable -mem-path for ppc but breaked some ppc
boards.

The problems are:

1. it fails when allocating memory for rom, sram whose sizes are less
   than huge page size:

   ./ppc-softmmu/qemu-system-ppc  -m 512 -mem-path /hugepages/ \
   -kernel /home/hutao/Downloads/vmlinux-ppc -initrd \
   /home/hutao/Downloads/initrd-ppc.gz
   qemu-system-ppc: /mnt/data/projects/qemu/exec.c:1184: qemu_ram_set_idstr: Assertion `new_block' failed.

2. if there is a numa node backed by memory backend object, qemu fails
   with message:

   ./ppc-softmmu/qemu-system-ppc  -m 512 \
   -object memory-backend-file,size=512M,mem-path=/hugepages,id=f0 \
   -numa node,nodeid=0,memdev=f0 \
   -kernel /home/hutao/Downloads/vmlinux-ppc \
   -initrd /home/hutao/Downloads/initrd-ppc.gz
   qemu-system-ppc: memory backend f0 is used multiple times. Each -numa option must use a different memdev value.

This patch does following:

1. replaces memory_region_allocate_system_memory() with
   memory_region_init_ram() for rom, sram. Then only system memory
   is backed by hugepages when specifying mem-path.

2. for memory banks, allocates all ram with
   one memory_region_allocate_system_memory(), and use
   memory_region_init_alias() to initialize memory banks.

Tested machines: default(g3beige), mac99, taihu, bamboo, ref405ep.
Signed-off-by: NHu Tao <hutao@cn.fujitsu.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

* remotes/amit-virtio-rng/for-2.1:
  virtio-rng: Add human-readable error message for negative max-bytes parameter
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>