This was done in a mostly automated fashion. I did it in three steps and then
rebased it into a single step which avoids repeatedly touching every file in
the tree.
The first step was a sed-based addition of the parent type to the subclass
registration functions.
The second step was another sed-based removal of subclass registration functions
while also adding virtual functions from the base class into a class_init
function as appropriate.
Finally, a python script was used to convert the DeviceInfo structures and
qdev_register_subclass functions to TypeInfo structures, class_init functions,
and type_register_static calls.
We are almost fully converted to QOM after this commit.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
These are various small stylistic changes which help make things more
consistent such that the automated conversion script can be simpler.
It's not necessary to agree or disagree with these style changes because all
of this code is going to be rewritten by the patch monkey script anyway.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Right now, DeviceInfo acts as the class for qdev. In order to switch to a
proper ObjectClass derivative, we need to ween all of the callers off of
interacting directly with the info pointer.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There is a device tree property "/chosen/linux,stdout-path" which indicates
which device should be used as stdout - ie. "the console".
Currently we don't specify anything, which means both firmware and Linux
choose something arbitrarily. Use the routine we added in the last patch
to pick a default vty and specify it as stdout.
Currently SLOF doesn't use the property, but we are hoping to update it
to do so.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
In vty_lookup() we have a special case for supporting early debug in
the kernel. This accepts reg == 0 as a special case to mean "any vty".
We implement this by searching the vtys on the bus and returning the
first we find. This means that the vty we chose depends on the order
the vtys are specified on the QEMU command line - because that determines
the order of the vtys on the bus.
We'd rather the command line order was irrelevant, so instead return
the vty with the lowest reg value. This is still a guess as to what the
user really means, but it is at least stable WRT command line ordering.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
[agraf] fix braces
For forgotten historical reasons, PAPR hypercalls for specific virtual IO
devices (oh which there are quite a number) are registered via a callback
in the VIOsPAPRDeviceInfo structure.
This is kind of ugly, so this patch instead registers hypercalls from
device_init() functions for each device type. This works just as well,
and is cleaner.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
The PAPR specification defines a virtual TTY/console interface for guest
OSes to use via the H_PUT_TERM_CHAR and H_GET_TERM_CHAR hypercalls. There
can be multiple virtual ttys, so these take a "termno" parameter. This
encodes which vty to use as the 'reg' property on the device tree node
associated with that vty.
However, with the early debug options enabled, the Linux kernel will
attempt debugging output through the vty very early, before it has read
the device tree. In this case it always uses a termno of 0. This works
on the existing PowerVM hypervisor, so we assume there must be a hack /
feature in there which interprets termno==0 to mean the default primary
console.
To help with debugging kernels, including existing distribution kernels,
this patch implements a similar feature / hack in qemu. If termno==0
is supplied to H_{GET,PUT}_TERM_CHAR, they use the first available vty
device instead.
We need to be careful in the case that the user has manually created
an spapr-vty at address 0. So first we search for the specified reg and
only if that doesn't match do we fall back.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
In commit b4a7852735 ("Place pseries vty
devices at addresses more similar to existing machines"), we changed the
default reg for the vty to 0x30000000, however we didn't update the default
value for a user specified vty device. Fix that.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
If qemu is run like:
qemu-system-ppc64 -nodefaults -device spapr-vty
We end up in spapr_vty_init() with dev->chardev == NULL. Currently
that leads to a segfault because we unconditionally call
qemu_chr_add_handlers().
Although we could make that call conditional, I think a spapr-vty
without a chardev is basically useless so fail the init. This is
similar to what the serial code does for example.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Restructure common properties for sPAPR devices so that IRQ definitions
can be added in one place.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Right now the spapr devices cannot be instantiated with -device,
because the IRQs need to be passed to the spapr_*_create functions.
Do this instead in the bus's init wrapper.
This is particularly important with the conversion from scsi-disk
to scsi-{cd,hd} that Markus made. After his patches, if you
specify a scsi-cd device attached to an if=none drive, the default
VSCSI controller will not be created and, without qdevification,
you will not be able to add yours.
NOTE from agraf: added small compile fix
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
Now that we have implemented the PAPR "xics" virtualized interrupt
controller, we can add interrupts in PAPR VIO devices. This patch adds
interrupt support to the PAPR virtual tty/console device.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This extends the "pseries" (PAPR) machine to include a virtual IO bus
supporting the PAPR defined hypercall based virtual IO mechanisms.
So far only one VIO device is provided, the vty / vterm, providing
a full console (polled only, for now).
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
