c5f52875 changed the size of sense array in vmstate_scsi_device by
mistake. This patch restores the old size, and add a subsection for the
remaining part of the buffer size. So that migration is not broken.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Normally VIOSRP_OK (0) means success and non-zero value means error
except VIOSRP_OK2 (0x99) which is another success code by weird accident.
This uses 0 as success code always as some guests do not cope with
the 0x99 value well. The existing linux driver checks for both VIOSRP_OK
and VIOSRP_OK2 since 2.6.32.
This returns non-zero code (VIOSRP_ADAPTER_FAIL == 0x10) on errors which
can only happen if DMA write failed.
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When running under qtest we don't actually have any vcpu threads
to be starved, so the warning about the I/O thread spinning isn't
relevant, and the way qtest manipulates the simulated clock means
the warning is produced a lot as a false positive. Suppress it if
qtest_enabled(), so 'make check' output is less noisy.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
If an assertion fails during qtest_init() the SIGABRT handler is
invoked. This is the correct behavior since we need to kill the QEMU
process to avoid leaking it when the test dies.
The global_qtest pointer used by the SIGABRT handler is currently only
assigned after qtest_init() returns. This results in a segfault if an
assertion failure occurs during qtest_init().
Move global_qtest assignment inside qtest_init(). Not pretty but let's
face it - the signal handler depends on global state.
Reported-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
A test is only as good as its coverage - testing virtserialport in
addition to virtconsole showed that commit
0399a3819b (virtio-console: QOM cast
cleanup for VirtConsole) broke virtserialport.
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Commit 0399a3819b (virtio-console: QOM
cast cleanup for VirtConsole) broke virtserialport since it shares
functions and state struct with virtconsole. Let virtconsole inherit
from virtserialport, and use virtserialport type for casting.
Note that virtio-serial-port is the abstract base type in
virtio-serial-bus.c, whereas virtserialport is the user-instantiatable
type in virtio-console.c. Therefore using TYPE_VIRTIO_CONSOLE_SERIAL_PORT.
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Before spapr_vga_init will returned false if the vga is specified by
the command '-device VGA' because vga_interface_type was evaluated to
VGA_NONE. With the change in previous patch of this series,
spapr_vga_init should return true if it's told that the vga will be
initialized in flow of the generic devices initialization.
To keep '-nodefaults' have the semantics of bare minimum, it adds a
check of 'has_defaults' in usb_enabled() to avoid that a USB controller
is added by '-nodefautls, -device VGA' implicitly.
This patch also makes two cleanups:
1. skip initialization for VGA_NONE
2. remove the useless 'break'
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Mark Wu <wudxw@linux.vnet.ibm.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Some machine (like pseries) initialization code determines if it has
graphics according to vga_interface_type. In the original code,
vga_interface_type is evaluated to VGA_NONE even if a VGA is added
via '-device VGA'. It causes the machine not aware of the graphics
device configured. Add a new VGA device type to indicate that it has a
VGA device, which will be initialized in QOM device initialization.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Mark Wu <wudxw@linux.vnet.ibm.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Raven datasheet explains where firmware lives in system memory, so do
it there instead of in board code. Other boards using the same PCI
host will not have to copy the firmware loading code.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
[AF: Drop BIOS size workaround in favor of replacing our firmware blob]
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Most targets were using offsetof(CPUFooState, breakpoints) to determine
how much of CPUFooState to clear on reset. Use the next field after
CPU_COMMON instead, if any, or sizeof(CPUFooState) otherwise.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Note that while such functions may exist both for *-user and softmmu,
only *-user uses the CPUState hook, while softmmu reuses the prototype
for calling it directly.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Remove the custom qemu_assert() function defined by target-m68k/translate.c
in favour of either using glib g_assert_not_reached() (for the genuinely
can't-happen cases) or cpu_abort() (for the "this isn't implemented",
in line with other unimplemented cases in the target).
This has the benefit of silencing some clang warnings about
variables used while uninitialized (which are emitted because
clang can't figure out that qemu_assert(0, something) never
returns.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
