aux_create_slave() calls qdev_init_nofail() which in turn "realizes"
the corresponding object. This is unlike qdev_create(), and it is wrong
because qdev_init_nofail() must not be called from an instance_init
function.  Move qdev_init_nofail() and the subsequent aux_map_slave into
the caller's realize function.

There are two more bugs that needs to be fixed here, too, where the
objects are created but not added as children.  Therefore when
you call object_unparent on them, nothing happens.

In particular dpcd and edid give you an infinite loop in bus_unparent,
because device_unparent is not called and does not remove them from
the list of devices on the bus.
Reported-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-17-git-send-email-thuth@redhat.com
[thuth: Added Paolo's fixup for the dpcd and edid unparenting]
Signed-off-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Valgrind complains:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'stm32f205-soc'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==28531== Invalid read of size 8
==28531==    at 0x6185BA: qdev_print (qdev-monitor.c:686)
==28531==    by 0x6185BA: qbus_print (qdev-monitor.c:719)
==28531==    by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]

Fix it with the new sysbus_init_child_obj() function.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-16-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Valgrind complains:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'allwinner-a10'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==32519== Invalid read of size 8
==32519==    at 0x61869A: qdev_print (qdev-monitor.c:686)
==32519==    by 0x61869A: qbus_print (qdev-monitor.c:719)
==32519==    by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]

Use object_initialize_child() and sysbus_init_child_obj() to fix the issue.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-15-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'realview_mpcore'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==2654== Invalid read of size 8
==2654==    at 0x61878A: qdev_print (qdev-monitor.c:686)
==2654==    by 0x61878A: qbus_print (qdev-monitor.c:719)
==2654==    by 0x452B38: handle_hmp_command (monitor.c:3446)
==2654==    by 0x452D70: qmp_human_monitor_command (monitor.c:821)
[...]

Use sysbus_init_child_obj() to fix it.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-14-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Valgrind reports an error here:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'arm11mpcore_priv'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==3145== Invalid read of size 8
==3145==    at 0x61873A: qdev_print (qdev-monitor.c:686)
==3145==    by 0x61873A: qbus_print (qdev-monitor.c:719)
[...]

Use sysbus_init_child_obj() to fix it.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-13-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Running QEMU with valgrind indicates a problem here:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'fsl,imx31'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==26172== Invalid read of size 8
==26172==    at 0x6191FA: qdev_print (qdev-monitor.c:686)
==26172==    by 0x6191FA: qbus_print (qdev-monitor.c:719)
[...]

Use the new sysbus_init_child_obj() to make sure that the objects are
cleaned up correctly when the parent gets destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-12-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Running QEMU with valgrind indicates a problem here:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'fsl,imx25'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==26724== Invalid read of size 8
==26724==    at 0x6190DA: qdev_print (qdev-monitor.c:686)
==26724==    by 0x6190DA: qbus_print (qdev-monitor.c:719)
[...]

Use the new sysbus_init_child_obj() to make sure that the objects are
cleaned up correctly when the parent gets destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-11-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Running QEMU with valgrind indicates a problem here:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'fsl,imx7'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==27284== Invalid read of size 8
==27284==    at 0x618F7A: qdev_print (qdev-monitor.c:686)
==27284==    by 0x618F7A: qbus_print (qdev-monitor.c:719)
==27284==    by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]

Use the new sysbus_init_child_obj() and object_initialize_child() to make
sure that the objects are removed correctly when the parent gets destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-10-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Running QEMU with valgrind indicates a problem here:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'fsl,imx6'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==32417== Invalid read of size 8
==32417==    at 0x618A7A: qdev_print (qdev-monitor.c:686)
==32417==    by 0x618A7A: qbus_print (qdev-monitor.c:719)
==32417==    by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]

Use the new sysbus_init_child_obj() and object_initialize_child() to make
sure that the objects are removed correctly when the parent gets destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-9-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Running QEMU with valgrind indicates a problem here:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'a9mpcore_priv'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==30996== Invalid read of size 8
==30996==    at 0x6185DA: qdev_print (qdev-monitor.c:686)
==30996==    by 0x6185DA: qbus_print (qdev-monitor.c:719)
==30996==    by 0x452B38: handle_hmp_command (monitor.c:3446)
[...]

Use the new sysbus_init_child_obj() function to make sure that the objects
are cleaned up correctly when the parent gets destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-8-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Valgrind currently reports a problem when running QEMU like this:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'msf2-soc'}}" \
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
[...]
==23097== Invalid read of size 8
==23097==    at 0x6192AA: qdev_print (qdev-monitor.c:686)
==23097==    by 0x6192AA: qbus_print (qdev-monitor.c:719)
[...]

Use the new sysbus_init_child_obj() function to make sure that the child
objects are cleaned up correctly when the parent gets destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-7-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

There is a memory management problem when introspecting the a15mpcore_priv
device. It can be seen with valgrind when running QEMU like this:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'a15mpcore_priv'}}"\
 "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}"  | \
 valgrind -q aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
 "package": "build-all"}, "capabilities": []}}
{"return": {}}
{"return": [{"name": "num-cpu", "type": "uint32"}, {"name": "num-irq",
 "type": "uint32"}, {"name": "a15mp-priv-container[0]", "type":
  "child<qemu:memory-region>"}]}
==24978== Invalid read of size 8
==24978==    at 0x618EBA: qdev_print (qdev-monitor.c:686)
==24978==    by 0x618EBA: qbus_print (qdev-monitor.c:719)
[...]

Use the new sysbus_init_child_obj() function to make sure that we get
the reference counting of the child objects right.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-6-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

QEMU currently crashes when introspecting the "iotkit" device and
runnint "info qtree" afterwards, e.g. when running QEMU like this:

echo "{'execute':'qmp_capabilities'} {'execute':'device-list-properties'," \
 "'arguments':{'typename':'iotkit'}}" "{'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 aarch64-softmmu/qemu-system-aarch64 -M none,accel=qtest -qmp stdio

Use the new functions object_initialize_child() and sysbus_init_child_obj()
to make sure that all objects get cleaned up correctly when the instances
are destroyed.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-5-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

When trying to "device_add bcm2837" on a machine that is not suitable for
this device, you can quickly crash QEMU afterwards, e.g. with "info qtree":

echo "{'execute':'qmp_capabilities'} {'execute':'device_add', " \
 "'arguments':{'driver':'bcm2837'}} {'execute': 'human-monitor-command', " \
 "'arguments': {'command-line': 'info qtree'}}" | \
 aarch64-softmmu/qemu-system-aarch64 -M integratorcp,accel=qtest -S -qmp stdio

{"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
 "package": "build-all"}, "capabilities": []}}
{"return": {}}
{"error": {"class": "GenericError", "desc": "Device 'bcm2837' can not be
 hotplugged on this machine"}}
Segmentation fault (core dumped)

The qdev_set_parent_bus() from instance_init adds a link to the child devices
which is not valid anymore after the bcm2837 instance has been destroyed.
Unfortunately, the child devices do not get destroyed / unlinked correctly
because both object_initialize() and object_property_add_child() increase
the reference count of the child objects by one, but only one reference
is dropped when the parent gets removed. So let's use the new functions
object_initialize_child() and sysbus_init_child_obj() instead to create
the objects, which will take care of creating the child objects with the
correct reference count of one.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531745974-17187-4-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

A lot of functions are initializing an object and attach it immediately
afterwards to the system bus. Provide a common function for this, which
also uses object_initialize_child() to make sure that the reference
counter is correctly initialized to 1 afterwards.
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
Message-id: 1531745974-17187-3-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

A lot of code is using the object_initialize() function followed by a call
to object_property_add_child() to add the newly initialized object as a child
of the current object. Both functions increase the reference counter of the
new object, but many spots that call these two functions then forget to drop
one of the superfluous references. So the newly created object is often not
cleaned up correctly when the parent is destroyed. In the worst case, this
can cause crashes, e.g. because device objects are not correctly removed from
their parent_bus.

Since this is a common pattern between many code spots, let's introduce a
new function that takes care of calling all three required initialization
functions, first object_initialize(), then object_property_add_child() and
finally object_unref(). And since the function does a similar job like
object_new_with_props(), also allow to set additional properties via
varargs, and use user_creatable_complete() to make sure that the functions
can be used similarly.

And while we're at object.h, also fix some copy-n-paste errors in the
comments there ("to store the area" --> "to store the error").
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Message-id: 1531745974-17187-2-git-send-email-thuth@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

qemu-ga patch queue for hard-freeze

* fix file descriptor leak in suspend command
* fix leak in guest-get-fsinfo

# gpg: Signature made Mon 16 Jul 2018 22:41:41 BST
# gpg:                using RSA key 3353C9CEF108B584
# gpg: Good signature from "Michael Roth <flukshun@gmail.com>"
# gpg:                 aka "Michael Roth <mdroth@utexas.edu>"
# gpg:                 aka "Michael Roth <mdroth@linux.vnet.ibm.com>"
# Primary key fingerprint: CEAC C9E1 5534 EBAB B82D  3FA0 3353 C9CE F108 B584

* remotes/mdroth/tags/qga-pull-2018-07-16-tag:
  qga: fix file descriptor leak
  qga: fix 'driver' leak in guest-get-fsinfo
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The file descriptor for /sys/power/state was never closed.  Reported
by Coverity.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

'driver' is leaked when the loop is not broken.

Leak introduced by commit 743c71d0,
spotted by ASAN.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

target-arm queue:
 * accel/tcg: Use correct test when looking in victim TLB for code
 * bcm2835_aux: Swap RX and TX interrupt assignments
 * hw/arm/bcm2836: Mark the bcm2836 / bcm2837 devices with user_creatable = false
 * hw/intc/arm_gic: Fix handling of GICD_ITARGETSR
 * hw/intc/arm_gic: Check interrupt number in gic_deactivate_irq()
 * aspeed: Implement write-1-{set, clear} for AST2500 strapping
 * target/arm: Fix LD1W and LDFF1W (scalar plus vector)

# gpg: Signature made Mon 16 Jul 2018 17:38:36 BST
# gpg:                using RSA key 3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>"
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20180716:
  accel/tcg: Assert that tlb fill gave us a valid TLB entry
  accel/tcg: Use correct test when looking in victim TLB for code
  bcm2835_aux: Swap RX and TX interrupt assignments
  hw/arm/bcm2836: Mark the bcm2836 / bcm2837 devices with user_creatable = false
  hw/intc/arm_gic: Fix handling of GICD_ITARGETSR
  hw/intc/arm_gic: Check interrupt number in gic_deactivate_irq()
  aspeed: Implement write-1-{set, clear} for AST2500 strapping
  target/arm: Fix LD1W and LDFF1W (scalar plus vector)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

In commit 4b1a3e1e we added a check for whether the TLB entry
we had following a tlb_fill had the INVALID bit set.  This could
happen in some circumstances because a stale or wrong TLB entry was
pulled out of the victim cache.  However, after commit
68fea038 (which prevents stale entries being in the victim
cache) and the previous commit (which ensures we don't incorrectly
hit in the victim cache)) this should never be possible.

Drop the check on TLB_INVALID_MASK from the "is this a TLB_RECHECK?"
condition, and instead assert that the tlb fill procedure has given
us a valid TLB entry (or longjumped out with a guest exception).
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180713141636.18665-3-peter.maydell@linaro.org

In get_page_addr_code(), we were incorrectly looking in the victim
TLB for an entry which matched the target address for reads, not
for code accesses. This meant that we could hit on a victim TLB
entry that indicated that the address was readable but not
executable, and incorrectly bypass the call to tlb_fill() which
should generate the guest MMU exception. Fix this bug.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180713141636.18665-2-peter.maydell@linaro.org

RX and TX interrupt bits were reversed, resulting in an endless sequence
of serial interupts in the emulated system and the following repeated
error message when booting Linux.

serial8250: too much work for irq61

This results in a boot failure most of the time.

Qemu command line used to reproduce the problem:

	qemu-system-aarch64 -M raspi3 -m 1024 \
	-kernel arch/arm64/boot/Image \
	--append "rdinit=/sbin/init console=ttyS1,115200"
	-initrd rootfs.cpio \
	-dtb arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb \
	-nographic -monitor null -serial null -serial stdio

This is with arm64:defconfig. The root file system was generated using
buildroot.

NB that this error likely arises from an erratum in the
BCM2835 datasheet where the TX and RX bits were swapped
in the AU_MU_IER_REG description (but correct for IIR):
 https://elinux.org/BCM2835_datasheet_errata#p12Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Message-id: 1529355846-25102-1-git-send-email-linux@roeck-us.net
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
[PMM: added NB about datasheet]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

These devices are currently causing some problems when a user is trying
to hot-plug or introspect them during runtime. Since these devices can
not be instantiated by the user at all (they need to be wired up in code
instead), we should mark them with user_creatable = false anyway, then we
avoid at least the crashes with the hot-plugging. The introspection problem
will be handled by a separate patch.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1531415537-26037-1-git-send-email-thuth@redhat.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The GICD_ITARGETSR implementation still has some 11MPCore behaviour
that we were incorrectly using in our GICv1 and GICv2 implementations
for the case where the interrupt number is less than GIC_INTERNAL.
The desired behaviour here is:
 * for 11MPCore: RAZ/WI for irqs 0..28; read a number matching the
   CPU doing the read for irqs 29..31
 * for GICv1 and v2: RAZ/WI if uniprocessor; otherwise read a
   number matching the CPU doing the read for all irqs < 32

Stop squashing GICD_ITARGETSR to 0 for IRQs 0..28 unless this
is an 11MPCore GIC.
Reported-by: NJan Kiszka <jan.kiszka@web.de>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180712154152.32183-3-peter.maydell@linaro.org

In gic_deactivate_irq() the interrupt number comes from the guest
(on a write to the GICC_DIR register), so we need to sanity check
that it isn't out of range before we use it as an array index.
Handle this in a similar manner to the check we do in
gic_complete_irq() for the GICC_EOI register.

The array overrun is not disastrous because the calling code
uses (value & 0x3ff) to extract the interrupt field, so the
only out-of-range values possible are 1020..1023, which allow
overrunning only from irq_state[] into the following
irq_target[] array which the guest can already manipulate.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180712154152.32183-2-peter.maydell@linaro.org

The AST2500 SoC family changes the runtime behaviour of the hardware
strapping register (SCU70) to write-1-set/write-1-clear, with
write-1-clear implemented on the "read-only" SoC revision register
(SCU7C). For the the AST2400, the hardware strapping is
runtime-configured with read-modify-write semantics.
Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Message-id: 20180709143524.17480-1-andrew@aj.id.au
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

'I' was being double-incremented; correctly within the inner loop
and incorrectly within the outer loop.
Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NLaurent Desnogues <laurent.desnogues@gmail.com>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Tested-by: NAlex Bennée <alex.bennee@linaro.org>
Message-id: 20180711103957.3040-1-richard.henderson@linaro.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Miscellaneous patches for 2018-07-16 (3.0.0-rc1)

# gpg: Signature made Mon 16 Jul 2018 14:50:07 BST
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-misc-2018-07-16:
  monitor: Fix tracepoint crash on JSON syntax error
  MAINTAINERS: New section "Incompatible changes", copy libvir-list
  qemu-doc: Move appendix "Deprecated features" to its own file
  cli qmp: Mark --preconfig, exit-preconfig experimental
  qapi: Do not expose "allow-preconfig" in query-qmp-schema
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

When tracepoint handle_qmp_command is enabled, we crash on JSON syntax
errors.  Broken in commit 1cc37471.  Fix by skipping the tracepoint
on JSON syntax error.  Before the flawed commit, we skipped it by
returning early.

Fixes: CID 1394216
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180716091012.29510-1-armbru@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NPeter Xu <peterx@redhat.com>

Libvirt developers would like to be copied on patches to qemu-doc
appendix "Deprecated features".  Do them the favor.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180716073226.21127-3-armbru@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Consumers of QEMU need to track feature deprecation.  Keeping
deprecation documentation in its own file helps in two small ways:

* You can track changes the easy and obvious way, with git-log.
  Before, you had to resort to more complex gittery like "git-log
  --oneline -L '/@node Deprecated features/,/@node Supported build
  platforms/:qemu-doc.texi'"

* It lets us use MAINTAINERS to copy interested parties on deprecation
  patches, so they can advise or object before they're a done deal.
  The next commit will do that for libvirt.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180716073226.21127-2-armbru@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Committing to the current --preconfig / exit-preconfig interface
before it has seen any use is premature.  Mark both as experimental,
the former in documentation, the latter by renaming it to
x-exit-preconfig.

See the previous commit for more detailed rationale.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180705091402.26244-3-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NIgor Mammedov <imammedo@redhat.com>
[Straightforward conflict with commit 514337c1 resolved]

According to commit 047f7038, option --preconfig

    [...] allows pausing QEMU in the new RUN_STATE_PRECONFIG state,
    allowing the configuration of QEMU from QMP before the machine
    jumps into board initialization code of machine_run_board_init()

    The intent is to allow management to query machine state and
    additionally configure it using previous query results within one
    QEMU instance (i.e. eliminate the need to start QEMU twice, 1st to
    query board specific parameters and 2nd for actual VM start using
    query results for additional parameters).

The implementation is a bit of a hack: it splices in an additional
main loop before machine creation, in special runstate preconfig.  New
command exit-preconfig exits that main loop.  QEMU continues
initializing, creates the machine, and runs the good old main loop.
The replacement of the main loop is transparent to monitors.

Sadly, some commands expect initialization to be complete.  Running
them in --preconfig's main loop violates their preconditions.  Since
we don't really know which commands are safe, we use a whitelist.
This drags the concept of run state into the QMP core.

The whitelist is done as a command flag in the QAPI schema (commit
d6fe3d02).  Drags the concept of run state further into the QAPI
language.

The command flag is exposed in query-qmp-schema (also commit
d6fe3d02).  This makes it ABI.

I consider the whole thing an offensively ugly hack, but sometimes an
ugly hack is the best we can do to solve a problem people have.

The need described by the commit message quote above is genuine.  The
proper solution would be a main loop that permits complete
configuration via QMP.  This is out of reach, thus the hack.

However, even though the need is genuine, it isn't urgent: libvirt is
not going to use this anytime soon.  Baking a hack into ABI before it
has any users is a bad idea.

This commit reverts the parts of commit d6fe3d02 that affect ABI
via query-qmp-schema.  The commit did the following:

(1) Add command flag 'allow-preconfig' to the QAPI schema language

(2) Pass it to code generators

(3) Have the commands.py code generator pass it to the command
    registry (so commit 047f7038 can use it as whitelist)

(4) Add 'allow-preconfig' to SchemaInfoCommand (neglecting to update
    qapi-code-gen.txt section "Client JSON Protocol introspection")

(5) Set 'allow-preconfig': true for commands qmp_capabilities,
    query-commands, query-command-line-options, query-status

Revert exactly (4), plus a bit of documentation added to
qemu-tech.info in commit 047f7038.

Shrinks query-qmp-schema's output from 126.5KiB to 121.8KiB for me.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180705091402.26244-2-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NIgor Mammedov <imammedo@redhat.com>
[Straightforward conflict with commit d626b6c1 resolved]

ppc patch queue 2018-07-16

Here's my first hard freeze pull request for qemu-3.0.  This contains
an assortment of bugfixes. Several are for regressions, others are for
bugs that I think are significant enough to address during hard freeze.

# gpg: Signature made Mon 16 Jul 2018 09:28:37 BST
# gpg:                using RSA key 6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg:                 aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg:                 aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# gpg:                 aka "David Gibson (kernel.org) <dwg@kernel.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-3.0-20180716:
  sm501: Fix warning about unreachable code
  sam460ex: Correct use after free error
  etsec: fix IRQ (un)masking
  ppc/xics: fix ICP reset path
  spapr: Correct inverted test in spapr_pc_dimm_node()
  sm501: Update screen on frame buffer address change
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Some fixes for linux-user:
- workaround for CMSG_NXTHDR bug
- two patches for ppc64/ppc64le host:
  fix fcntl() with *LK64 commands
  (seen when dpkg wants to lock the DB)
  fix reserved_va alignment (ppc64 needs
  a 64kB alignment)
- convert a forgotten fcntl() to safe_fcntl()

# gpg: Signature made Sun 15 Jul 2018 20:51:19 BST
# gpg:                using RSA key F30C38BD3F2FBE3C
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>"
# gpg:                 aka "Laurent Vivier <laurent@vivier.eu>"
# gpg:                 aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>"
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C

* remotes/vivier2/tags/linux-user-for-3.0-pull-request:
  Zero out the host's `msg_control` buffer
  linux-user: fix mmap_find_vma_reserved()
  linux-user: convert remaining fcntl() to safe_fcntl()
  linux-user: ppc64: use the correct values for F_*LK64s
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Coverity warned that the false arm of conditional expression is
unreachable when it is inside an if with the same condition.
Remove the unreachable code to avoid the warning.

Fixes: CID 1394215
Reported-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Commit 51b0d834 changed error handling to report file name in error
message but forgot to move freeing it after usage. Noticed by Coverity.

Fixes: CID 1394217
Reported-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Interrupt conditions occurring while masked are not being
signaled when later unmasked.
The fix is to raise/lower IRQs when IMASK is changed.

To avoid problems like this in future, consolidate
IRQ pin update logic in one function.

Also fix probable typo "IEVENT_TXF | IEVENT_TXF",
and update IRQ pins on reset.
Signed-off-by: NMichael Davidsaver <mdavidsaver@gmail.com>
Reviewed-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Recent cleanup in commit a028dd42 dropped the ICPStateClass::reset
handler. It is now up to child ICP classes to call the DeviceClass::reset
handler of the parent class, thanks to device_class_set_parent_reset().
This is a better object programming pattern, but unfortunately it causes
QEMU to crash during CPU hotplug:

(qemu) device_add host-spapr-cpu-core,id=core1,core-id=1
Segmentation fault (core dumped)

When the hotplug path tries to reset the ICP device, we end up calling:

static void icp_kvm_reset(DeviceState *dev)
{
    ICPStateClass *icpc = ICP_GET_CLASS(dev);

    icpc->parent_reset(dev);

but icpc->parent_reset is NULL... This happens because icp_kvm_class_init()
calls:

    device_class_set_parent_reset(dc, icp_kvm_reset,
                                  &icpc->parent_reset);

but dc->reset, ie, DeviceClass::reset for the TYPE_ICP type, is
itself NULL.

This patch hence sets DeviceClass::reset for the TYPE_ICP type to
point to icp_reset(). It then registers a reset handler that calls
DeviceClass::reset. If the ICP subtype has configured its own reset
handler with device_class_set_parent_reset(), this ensures it will
be called first and it can then call ICPStateClass::parent_reset
safely. This fixes the reset path for the TYPE_KVM_ICP type, which
is the only subtype that defines its own reset function.
Reported-by: NSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au>
Fixes: a028dd42Signed-off-by: NGreg Kurz <groug@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>