QOM child properties take a reference to the object and release it when
the property is deleted. Therefore we should unref the default_backend
after we have added it as a child property.
Cc: KONRAD Frederic <fred.konrad@greensocs.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
There are currently three types of object_property_add_link() callers:
1. The link property may be set at any time.
2. The link property of a DeviceState instance may only be set before
realize.
3. The link property may never be set, it is read-only.
Something similar can already be achieved with
object_property_add_str()'s set() argument. Follow its example and add
a check() argument to object_property_add_link().
Also provide default check() functions for case #1 and #2. Case #3 is
covered by passing a NULL function pointer.
Cc: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
[AF: Tweaked documentation comment]
Signed-off-by: Andreas Färber <afaerber@suse.de>
Some object_property_add_link() callers expect property deletion to
unref the link property object. Other callers expect to manage the
refcount themselves. The former are currently broken and therefore leak
the link property object.
This patch adds a flags argument to object_property_add_link() so the
caller can specify which refcount behavior they require. The new
OBJ_PROP_LINK_UNREF_ON_RELEASE flag causes the link pointer to be
unreferenced when the property is deleted.
This fixes refcount leaks in qdev.c, xilinx_axidma.c, xilinx_axienet.c,
s390-virtio-bus.c, virtio-pci.c, virtio-rng.c, and ui/console.c.
Rationale for refcount behavior:
* hw/core/qdev.c
- bus children are explicitly unreferenced, don't interfere
- parent_bus is essentially a read-only property that doesn't hold a
refcount, don't unref
- hotplug_handler is leaked, do unref
* hw/dma/xilinx_axidma.c
- rx stream "dma" links are set using set_link, therefore they
need unref
- tx streams are set using set_link, therefore they need unref
* hw/net/xilinx_axienet.c
- same reasoning as hw/dma/xilinx_axidma.c
* hw/pcmcia/pxa2xx.c
- pxa2xx bypasses set_link and therefore does not use refcounts
* hw/s390x/s390-virtio-bus.c
* hw/virtio/virtio-pci.c
* hw/virtio/virtio-rng.c
* ui/console.c
- set_link is used and there is no explicit unref, do unref
Cc: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
The error behavior of object_property_set_link() is dangerous. It sets
the link property object to NULL if an error occurs. A setter function
should either succeed or fail, it shouldn't leave the value NULL on
failure.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
The path resolution logic in object_property_set_link() should be a
separate function. This makes the code easier to read and maintain.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Machine rewriting added MACHINE() macro which is
already in use by other OpenBSD library.
Since qemu/sockets.h exposes the OpenBSD namespace,
the minimalistic approach is to add it as the first QEMU include.
Reported-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Since commit 261747f176 (vl: Use MachineClass instead of global
QEMUMachine list) valgrind complains about the following:
==54082== 57 bytes in 3 blocks are definitely lost in loss record 365 of
729
==54082== at 0x4031AFE: malloc (vg_replace_malloc.c:292)
==54082== by 0x4145569: g_malloc (in
/usr/lib64/libglib-2.0.so.0.3400.2)
==54082== by 0x415F9E9: g_strconcat (in
/usr/lib64/libglib-2.0.so.0.3400.2)
==54082== by 0x80157FE7: qemu_register_machine (vl.c:1597)
==54082== by 0x80208E6B: module_call_init (module.c:105)
==54082== by 0x80013B91: main (vl.c:3000)
Turns out that valgrind is right. We simply forget the memory that
g_strconcat() has allocated. Lets free it after the type_register().
We need a 2nd variable due to constness of the name part of the
type structure.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Commit 259186a7d2 (cpu: Move halted and
interrupt_request fields to CPUState) passed CPUState::env_ptr to
tlb_flush() directory rather than through a typed variable.
Commit 00c8cb0a36 (cputlb: Change
tlb_flush() argument to CPUState) now changed the argument type.
This was unnoticed by gcc because env_ptr is a void pointer.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This fixes warnings from the static code analysis (smatch).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
* remotes/riku/linux-user-for-upstream:
linux-user: Implement capget, capset
linux-user: Don't allow guest to block SIGSEGV
signal: added a wrapper for sigprocmask function
linux-user: Don't reserve space for commpage for AArch64
linux-user: implement F_[GS]ETOWN_EX
linux-user: Don't return uninitialized value for atomic_barrier syscall
linux-user/signal.c: Correct error path for AArch64 do_rt_sigreturn
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When creating an IOThread implicitly (the user did not specify
x-iothread=<id>) remember that iothread_find() does not return the
object with an incremented refcount.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
if an NFS operation fails we should report what libnfs knows
about the failure. It is likely more than just an error code.
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
libnfs prior to 1.9.3 contains a bug that will report
wrong transfer sizes if the file offset grows beyond 4GB
and RPC responses are received out of order. this
error is not detectable and fixable in qemu.
additionally 1.9.3 introduces support for handling short
read/writes in general and takes care of the necessary
retransmissions internally.
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If qcow2_alloc_clusters() fails, new_offset and ret will both be
negative after the fail label, thus passing the first if condition and
subsequently resulting in a call of qcow2_free_clusters() with an
invalid (negative) offset parameter. Fix this by introducing a new label
"fail_free_cluster" which is only invoked if new_offset is indeed
pointing to a newly allocated cluster that should be cleaned up by
freeing it.
While we're at it, clean up the whole fail path. qcow2_cache_put()
should (and actually can) never fail, hence the return value can safely
be ignored (aside from asserting that it indeed did not fail).
Furthermore, there is no reason to give QCOW2_DISCARD_ALWAYS to
qcow2_free_clusters(), a mere QCOW2_DISCARD_OTHER will suffice.
Ultimately, rename the "fail" label to "done", as it is invoked both on
failure and success.
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Contrary to the comment describing this function's behavior, it does not
return 0 on success, but rather the offset of the newly allocated
cluster. This patch adjusts the comment accordingly to reflect the
actual behavior.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
It's not clear from the usage description that "--cmd" option accepts
its argument as a string, so any special symbols have to be quoted from
the shell.
Updates in usage text:
- Specified parameter format for "--cmd" option.
- Added an instruction how to get help for "--cmd" option.
Signed-off-by: Maria Kustova <maria.k@catit.be>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If it returns an error, the migrated VM will not be started, but qemu
exits with an error message.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Benoit Canet <benoit@irqsave.net>
Add the saturating accumulate operations USQADD and SUQADD
to the A64 instruction set. This completes coverage of A64 Neon.
These operations (which are unsigned + signed -> signed and
signed + unsigned -> unsigned) don't exist in the A32/T32
instruction set, so require a complete new set of helper functions.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <rth@twiddle.net>
This mostly re-uses the existing NEON helpers with an additional two for
the 64 bit case. I also took the opportunity to add TCG_CALL_NO_RWG
options to the helpers as they don't modify globals (saturation flags
are in the CPU Environment).
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <rth@twiddle.net>
The receive fifo full bit should be set when 1 character is received and
the fifo is disabled or when 16 characters are in the fifo.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1395166721-15716-4-git-send-email-robherring2@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Offset 4 is UARTRSR/UARTECR, not the UARTCR. The UARTCR would be
corrupted if the UARTRSR is ever written. Fix by implementing a correct
model of the UARTRSR/UARTECR register. Reads of this register simply
reflect the error bits in data register. Only breaks can be triggered in
QEMU. With the pl011_can_receive function, we effectively have flow
control between the host and the model. Framing and parity errors simply
don't make sense in the model and will never occur.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1395166721-15716-3-git-send-email-robherring2@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Intermittent issues have been seen where no serial input occurs. It
appears the pl011 gets in a state where the rx interrupt never fires
because the rx interrupt only asserts when crossing the fifo trigger
level. The fifo state appears to get out of sync when the pl011 is
re-configured. This combined with the rx timeout interrupt not being
modeled results in no more rx interrupts.
Disabling the fifo is the recommended way to clear the tx fifo in the
TRM (section 3.3.8). The behavior in this case for the rx fifo is
undefined in the TRM, but having fifo contents to be maintained during
configuration changes is not likely expected behavior. Reseting the
fifo state when the fifo size is changed is the simplest solution.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1395166721-15716-2-git-send-email-robherring2@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Non-PCI AHCI support is broken due to assertion failures when trying
to convert AHCIState to a PCIDevice pointer as AHCIState can have
different container structs. Fix this by using the non-asserting object
cast and checking the returned pointer is not NULL.
The AddressSpace pointer is also being initialized to NULL and causing
dma_memory_map call to fail. Fix this by initializing to
address_space_memory for sysbus instances.
Also correct AHCI_VMSTATE to use the correct container SysbusAHCIState
for sysbus instances.
Signed-off-by: Rob Herring <rob.herring@linaro.org>
Message-id: 1392073373-3295-1-git-send-email-robherring2@gmail.com
[PMM: added linebreaks to fix overlong lines]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
when using signature for table ID, we forgot to byte-swap it.
signatures are really ASCII strings, let's treat them as such.
While at it, get rid of most of _SIGNATURE macros.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Building on the previous patch, raise the maximal count of processor
objects / NTFY branches / CPON elements from 255 to 256. This allows the
VCPU with APIC ID 0xFF to be hotplugged.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
commit 9bcc80cd71
i386/acpi-build: allow more than 255 elements in CPON
Replaces 0x1 with a smaller One constant.
rebuild expected SSDT.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The build_ssdt() function builds a number of AML objects that are related
to CPU hotplug, and whose IDs form a contiguous sequence of APIC IDs.
(APIC IDs are in fact discontiguous, but this is the traditional
interface: build a contiguous sequence from zero up that covers all
possible APIC IDs.) These objects are:
- a Processor() object for each VCPU,
- a NTFY method, with one branch for each VCPU,
- a CPON package with one element (hotplug status byte) for each VCPU.
The build_ssdt() function currently limits the *count* of processor
objects, and NTFY branches, and CPON elements, in 0xFF (see the assignment
to "acpi_cpus"). This allows for an inclusive APIC ID range of [0..254].
This is incorrect, because the highest APIC ID that we otherwise allow a
VCPU to take is 255.
In order to extend the maximum count to 256, and the traversed APIC ID
range correspondingly to [0..255]:
- the Processor() objects need no change,
- the NTFY method also needs no change,
- the CPON package must be updated, because it is defined with a
DefPackage, and the number of elements in such a package can be at most
255. We pick a DefVarPackage instead.
We replace the Op byte, and the encoding of the number of elements.
Compare:
DefPackage := PackageOp PkgLength NumElements PackageElementList
DefVarPackage := VarPackageOp PkgLength VarNumElements PackageElementList
PackageOp := 0x12
VarPackageOp := 0x13
NumElements := ByteData
VarNumElements := TermArg => Integer
The build_append_int() function implements precisely the following TermArg
encodings (a subset of what the ACPI spec describes):
TermArg := DataObject
DataObject := ComputationalData
ComputationalData := ConstObj | ByteConst | WordConst | DWordConst
directly encoded in the function, with build_append_byte():
ConstObj := ZeroOp | OneOp
ZeroOp := 0x00
OneOp := 0x01
call to build_append_value(..., 1):
ByteConst := BytePrefix ByteData
BytePrefix := 0x0A
ByteData := 0x00 - 0xFF
call to build_append_value(..., 2):
WordConst := WordPrefix WordData
WordPrefix := 0x0B
WordData := ByteData[0:7] ByteData[8:15]
call to build_append_value(..., 4):
DWordConst := DWordPrefix DWordData
DWordPrefix := 0x0C
DWordData := WordData[0:15] WordData[16:31]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This changes the PC initialization code to reject max_cpus if it results
in an APIC ID that's too large, instead of aborting or erroring out when
it is already too late.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
MAX_CPUMASK_BITS is a limit for max_cpus and CPU indexes, not for APIC
IDs.
ACPI_CPU_HOTPLUG_ID_LIMIT is the right macro for the limit on APIC IDs
on the ACPI and CPU hotplug code.
There are no functional changes introduced by this patch, as
MAX_CPUMASK_BITS + 1 == 255 + 1 == 256 == ACPI_CPU_HOTPLUG_ID_LIMIT.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
AcpiCpuHotplug_add() can't handle vCPU arch IDs larger than
ACPI_CPU_HOTPLUG_ID_LIMIT. Instead of corrupting memory in case the vCPU
ID is too large, use g_assert() to ensure we are not over the limit.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The ACPI CPU hotplug code requires APIC IDs to be smaller than
ACPI_CPU_HOTPLUG_ID_LIMIT, so enforce the limit before trying to hotplug
a new vCPU, returning an error instead of crashing.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The new macro will be helpful to allow us to detect too large SMP limits
before it is too late.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
this fixes invalid rectangle updates observed after commit 12b316d
with the vmware VGA driver. The issues occured because the server
and client surface update seems to be out of sync at some points
and the max width of the surface is not dividable by
VNC_DIRTY_BITS_PER_PIXEL (16).
Reported-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
- Fixing findings of valgrind regarding minor memory leaks:
Currently we forget the pointer of qemu_allocate_irqs. Since we never
free the irqs, this is not critical, but obviously not good programming
style. While we are at it, we dont need the irq infrastructure for
the sclp consoles.
- Handle new ELF error codes for BIOS loading
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJTJ2pUAAoJEBF7vIC1phx8u/MP/RNd875pyFYamYF1aLKka7Ov
hGtTaVtvqtJjsvy57Av9LX3sT1bbafqNTYea8ZXJgMCggHHk+QM/zUSjkY3qZqxL
V15wCg1wlMXagjkZRwfCD+dGGJK3CQBQSsJ4q9szPeyAf/P1VPOblkR5k0YtqzU7
ZdjzxuizqnHekaHAfmCvURdngJIRa6C6abYS9oosfyZ4eWlivLrL02i82fYGHUVh
Nd2GylqHLZNy2laHzwKKeItw+Lu3O3bl6OY4kXqColyaNEMcuM3Helz0Z64QqLM+
SAataHtT2AJ4e+W+rXBT8StQ2/XB0n0q1StuKz4lceG/6VgZ52kH47Bv0yAr++Gl
GNyqfx3xMMCF61oqAO3OmAfmr1C8hW01ZM/CVS0yfQTXKtI1OsWTxbZxNygrRaL1
6Nkr35+8Tt6snKbFxTu7IAh5qVsXYb0cW3Dp5XqtFOPT0vedZkCycVZSFeM1JybT
NcZPZxT+3CoYFS7y6p/wq6gMcgUA4AT+ibOx7G/mQPyt+FBdGkU6jSV38H8NxpKM
XaeGvp0iuOrX8DBqMEPKPAW0z1uKwkyjHm/WSS1mwjcDAk7AOHRzCVRFG2MuTDQB
qIoN/Q9nR65mTTBbDypQqS7EmkVmLScLJRORrTi77d7OwB1zsf7KeauR6pB3gSyb
eT/YVXiwccxfz6bf/kOK
=u8Wg
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/borntraeger/tags/kvm-s390-20140317' into staging
4 small patches:
- Fixing findings of valgrind regarding minor memory leaks:
Currently we forget the pointer of qemu_allocate_irqs. Since we never
free the irqs, this is not critical, but obviously not good programming
style. While we are at it, we dont need the irq infrastructure for
the sclp consoles.
- Handle new ELF error codes for BIOS loading
# gpg: Signature made Mon 17 Mar 2014 21:34:12 GMT using RSA key ID B5A61C7C
# gpg: Can't check signature: public key not found
* remotes/borntraeger/tags/kvm-s390-20140317:
s390x/sclpconsole-lm: Fix and simplify irq setup
s390x/sclpconsole: Fix and simplify interrupt injection
s390x/cpu hotplug: Fix memory leak
s390/ipl: Fix error path on BIOS loading
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
valgrind complains about a memory leak in irq setup of sclpconsole:
==42117== 8 bytes in 1 blocks are definitely lost in loss record 89of 833
==42117== at 0x4031AFE: malloc (vg_replace_malloc.c:292)
==42117== by 0x8022F855: malloc_and_trace (vl.c:2715)
==42117== by 0x4145569: g_malloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==42117== by 0x800F696D: qemu_extend_irqs (irq.c:51)
==42117== by 0x800F6AF7: qemu_allocate_irqs (irq.c:68)
==42117== by 0x800F5685: console_init (sclpconsole.c:235)
==42117== by 0x80297C79: event_realize (event-facility.c:386)
==42117== by 0x80105071: device_set_realized (qdev.c:693)
==42117== by 0x801CDC4B: property_set_bool (object.c:1337)
==42117== by 0x801CBD7F: object_property_set (object.c:819)
[...]
We dont need the indirection of an qemu irq to inject an slcp interrupt.
Fixes a valgrind error and makes the code simpler.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
