As suffixes do not make sense for sPAPR's device tree and
there is no way to filter them out on the BusState::get_fw_dev_path()
level, let's add an ability for the external caller to specify
whether to apply suffixes or not.
We could handle suffixes in SLOF (ignored for now) but this would require
serious rework in the node opening code in SLOF, which has no obvious
benefit for the currently emulated sPAPR machine.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Replace them with uint8/32/64.
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
device_add plugs devices into suitable bus. For "real" buses, that
actually connects the device. For sysbus, the connections need to be
made separately, and device_add can't do that. The device would be
left unconnected, and could not possibly work.
Quite a few, but not all sysbus devices already set
cannot_instantiate_with_device_add_yet in their class init function.
Set it in their abstract base's class init function
sysbus_device_class_init(), and remove the now redundant assignments
from device class init functions.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
In an ideal world, machines can be built by wiring devices together
with configuration, not code. Unfortunately, that's not the world we
live in right now. We still have quite a few devices that need to be
wired up by code. If you try to device_add such a device, it'll fail
in sometimes mysterious ways. If you're lucky, you get an
unmysterious immediate crash.
To protect users from such badness, DeviceClass member no_user used to
make device models unavailable with -device / device_add, but that
regressed in commit 18b6dad. The device model is still omitted from
help, but is available anyway.
Attempts to fix the regression have been rejected with the argument
that the purpose of no_user isn't clear, and it's prone to misuse.
This commit clarifies no_user's purpose. Anthony suggested to rename
it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
I shorten somewhat to keep checkpatch happy. While there, make it
bool.
Every use of cannot_instantiate_with_device_add_yet gets a FIXME
comment asking for rationale. The next few commits will clean them
all up, either by providing a rationale, or by getting rid of the use.
With that done, the regression fix is hopefully acceptable.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
scripts/checkpatch.pl reports about some style problems,
this commit fixes some of them:
ERROR: space prohibited before open square bracket '['
+ .fields = (VMStateField []) {
ERROR: space prohibited after that '!' (ctx:BxW)
+ if (! eeprom->eecs && eecs) {
^
ERROR: space prohibited after that '!' (ctx:WxW)
+ } else if (eeprom->eecs && ! eecs) {
^
ERROR: space prohibited after that '!' (ctx:WxW)
+ } else if (eecs && ! eeprom->eesk && eesk) {
^
ERROR: switch and case should be at the same indent
switch (address >> (eeprom->addrbits - 2)) {
+ case 0:
[...]
+ case 1:
[...]
+ case 2:
[...]
+ case 3:
ERROR: return is not a function, parentheses are not required
+ return (eeprom->eedo);
ERROR: switch and case should be at the same indent
switch (nwords) {
+ case 16:
+ case 64:
[...]
+ case 128:
+ case 256:
[...]
+ default:
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Cc: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Cc: qemu-trivial@nongnu.org
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
In order to get devices appear in output of
"./qemu-system-ppc64 -device ?",
they must be assigned to one of DEVICE_CATEGORY_XXXX.
This puts VIO devices classes to corresponding categories.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
The I/O port variant of fw_cfg is used by sparc64, which is a big-endian machine.
Firmware swaps bytes before sending them to fw_cfg, so we need to unswap them in
the device.
This is only used on sparc64 and on (little-endian) x86, so it does not affect
any other target. 32-bit Sparc and PPC all use memory-mapped fw_cfg.
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-id: 1375014954-31916-2-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
[AF: Moved sysbus_init_mmio() to instance_init, renamed variable]
Signed-off-by: Andreas Färber <afaerber@suse.de>
Use type constant if possible and avoid DO_UPCAST().
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
[AF: Renamed parent field]
Signed-off-by: Andreas Färber <afaerber@suse.de>
RTAS is a hypervisor provided binary blob that a guest loads and
calls into to execute certain functions. It's similar to the
vsyscall page in Linux or the short lived VMCI paravirt interface
from VMware.
The QEMU implementation of the RTAS blob is simply a passthrough
that proxies all RTAS calls to the hypervisor via an hypercall.
While we pass a CPU argument for hypercall handling in QEMU, we
don't pass it for RTAS calls. Since some RTAs calls require
making hypercalls (normally RTAS is implemented as guest code) we
have nasty hacks to allow that.
Add a CPU argument to RTAS call handling so we can more easily
invoke hypercalls just as guest code would.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Make sure we only have a single instance ever:
because if it isn't we can't find it so it's
useless anyway.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Remove some code duplication by adding a
function to look up the fw cfg file.
This way, we don't need to duplicate same strings everywhere.
Use by both fw cfg and pvpanic device.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
firmware_abi.h with structs for OpenBIOS landed in hw/sparc/ by mistake
- move it to hw/nvram/ alongside fw_cfg.h. In addition to sparc it's
included from ppc mac_nvram.c and will need to include it from prep.c in
the future.
Acked-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This unbreaks cross compile builds:
configure --target-list="i386-softmmu" --cpu=i386
When building on a 64bit machine.
Reported-by: David Holsgrove <david.holsgrove@xilinx.com>
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Message-id: 926326e96fd8685d74e9d5bf430fe4ad97a55289.1369191585.git.peter.crosthwaite@xilinx.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This lets seabios patch the corresponding SSDT entry.
Also add fw_cfg object to /machine/fw_cfg so we can reference
it elsewhere.
Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-id: 60c65d95fe2b23b12bea67099126566010a11a1a.1366945969.git.hutao@cn.fujitsu.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Curerntly the pseries VIO device code contains quite a few explicit
uses of DO_UPCAST and plain C casts. This is (obviously) type unsafe,
and not the conventional way of doing things in the QOM model. This
patch converts the code to use the QOM convention of per-type macros
to do verified casts with OBJECT_CHECK().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Alexey Kardashevskiy