qdev: Replace no_user by cannot_instantiate_with_device_add_yet

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>
sysbus: Set cannot_instantiate_with_device_add_yet

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>
cpu: Document why cannot_instantiate_with_device_add_yet

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
apic: Document why cannot_instantiate_with_device_add_yet

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
pci-host: Consistently set cannot_instantiate_with_device_add_yet

Many PCI host bridges consist of a sysbus device and a PCI device.
You need both for the thing to work.  Arguably, these bridges should
be modelled as a single, composite devices instead of pairs of
seemingly independent devices you can only use together, but we're not
there, yet.

Since the sysbus part can't be instantiated with device_add, yet,
permitting it with the PCI part is useless.  We shouldn't offer
useless options to the user, so let's set
cannot_instantiate_with_device_add_yet for them.

It's already set for Bonito, Grackle, i440FX and Raven.  Document why.

Set it for the others: dec-21154, e500-host-bridge, gt64120_pci, mch,
pbm-pci, ppc4xx-host-bridge, sh_pci_host, u3-agp, uni-north-agp,
uni-north-internal-pci, uni-north-pci, and versatile_pci_host.

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>
ich9: Document why cannot_instantiate_with_device_add_yet

An ICH9 southbridge contains several PCI devices, some of them with
multiple functions.  We model each function as a separate qdev.  Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus controller at 00:1f.3.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
piix3 piix4: Clean up use of cannot_instantiate_with_device_add_yet

A PIIX3/PIIX4 southbridge has multiple functions.  We model each
function as a separate qdev.  Two of them need some special wiring set
up in pc_init1() or mips_malta_init() to work: the ISA bridge at 01.0,
and the SMBus controller at 01.3.

The IDE controller at 01.1 (piix3-ide, piix3-ide-xen, piix4-ide) has
always had cannot_instantiate_with_device_add_yet set, but there is no
obvious reason why device_add could not work for them.  Drop it.

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>
vt82c686: Clean up use of cannot_instantiate_with_device_add_yet

A VT82C686B southbridge has multiple functions.  We model each
function as a separate qdev.  One of them need some special wiring set
up in mips_fulong2e_init() to work: the ISA bridge at 05.0.

The IDE controller at 05.1 (via-ide) has always had
cannot_instantiate_with_device_add_yet set, but there is no obvious
reason why device_add could not work for them.  Drop it.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
isa: Clean up use of cannot_instantiate_with_device_add_yet

Drop it when there's no obvious reason why device_add could not work.
Else keep and document why.

* isa-fdc: drop

* i8042: drop, even though its I/O base is hardcoded (because you
  could conceivably still add one to a board that has none), and even
  though PC board code wires up the A20 line (because that wiring is
  optional)

* port92: keep because it needs additional wiring by port92_init()

* mc146818rtc: keep because it needs to be wired up by rtc_init()

* m48t59_isa: keep because needs to be wired up by m48t59_init_isa()

* isa-pit, kvm-pit: keep (in their abstract base pic-common) because
  the PIT needs additional wiring by board code, depending on HPET
  presence

* pcspk: keep because of pointer property pit, and because realize
  sets global pcspk_state

* vmmouse: keep because of pointer property ps2_mouse

* vmport: keep because realize sets global port_state

* isa-i8259, kvm-i8259: keep (in their abstract base pic-common),
  because the PICs' IRQ input lines are set up by board code, and the
  wiring of the slave to the master is hard-coded in device model code

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
qdev: Do not let the user try to device_add when it cannot work

Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help.  Until commit 18b6dad
silently broke the former, setting up nasty traps for unwary users,
like this one:

    $ qemu-system-x86_64 -nodefaults -monitor stdio -display none
    QEMU 1.6.50 monitor - type 'help' for more information
    (qemu) device_add apic
    Segmentation fault (core dumped)

I call that a regression.  Fix it.

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>
qdev-monitor: device_add crashes on non-device driver name, fix

Watch this:

    $ upstream-qemu -nodefaults -S -display none -monitor stdio
    QEMU 1.7.50 monitor - type 'help' for more information
    (qemu) device_add rng-egd
    /work/armbru/qemu/qdev-monitor.c:491:qdev_device_add: Object 0x2089b00 is not an instance of type device
    Aborted (core dumped)

Crashes because "rng-egd" exists, but isn't a subtype of TYPE_DEVICE.
Broken in commit 18b6dad.

Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
hw: cannot_instantiate_with_device_add_yet due to pointer props

Pointer properties can be set only by code, not by device_add.  A
device with a pointer property can work with device_add only when the
property may remain null.

This is the case for property "interrupt_vector" of device
"etraxfs,pic".  Add a comment there.

Set cannot_instantiate_with_device_add_yet for the other devices with
pointer properties, with a comment explaining why.

Juha Riihimäki and Peter Maydell deserve my thanks for making "pointer
property must not remain null" blatantly obvious in the OMAP devices.

Only device "smbus-eeprom" is actually changed.  The others are all
sysbus devices, which get cannot_instantiate_with_device_add_yet set
in their abstract base's class init function.  Setting it again in
their class init function is technically redundant, but serves as
insurance for when sysbus devices become available with device_add,
and as documentation.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com> (for ETRAX)
Signed-off-by: Andreas Färber <afaerber@suse.de>
qdev: Document that pointer properties kill device_add

Ask users of DEFINE_PROP_PTR() to set
cannot_instantiate_with_device_add_yet, or explain why it's not
needed.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
qom: Split out object and class caches

The object-cast and class-cast caches cannot be shared because class
caching is conditional on the target type not being an interface and
object caching is unconditional. Leads to a bug when a class cast
to an interface follows an object cast to the same interface type:

FooObject = FOO(obj);
FooClass = FOO_GET_CLASS(obj);

Where TYPE_FOO is an interface. The first (object) cast will be
successful and cache the casting result (i.e. TYPE_FOO will be cached).
The second (class) cast will then check the shared cast cache
and register a hit. The issue is, when a class cast hits in the cache
it just returns a pointer cast of the input class (i.e. the concrete
class).

When casting to an interface, the cast itself must return the
interface class, not the concrete class. The implementation of class
cast caching already ensures that the returned cast result is only
a pointer cast before caching. The object cast logic however does
not have this check.

Resolve by just splitting the object and class caches.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Nathan Rossi <nathan.rossi@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
qom: Do not register interface "types" in the type table and fix names

There should be no need to look them up nor enumerate the interface
"types", whose "classes" are really just vtables.  Just create the
types and add them to the interface list of the parent type.
Interfaces not registering their type anymore means that accessing
superclass::interface by type name will fail.

Further, the interface type rework had a bug with interfaces that are
inherited from a superclass:  The implementation type name was wrong
(for example it was subclass::superclass::interface rather than
just subclass::interface).

This can be fixed by pre-initializing ti->parent_type of subclass::interface
to superclass::interface.

Reported-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
test: QOM interface casting

Add basic regression testing for QOM Interface usage.
Test checks casting to interface type/class for following cases:
  - interface implementation in leaf class
  - interface implementation in intermediate (parent) class

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
qom: Detect bad reentrance during object_class_foreach()

We should not modify the type hash table while it is being iterated on.
Assert that it does not happen.

Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
qdev: Drop misleading qbus_free() function

Same reasoning as commit 02a5c4c97422b40034f31265e0f139f7846172a8
("qdev: Drop misleading qdev_free() function").  The qbus_free()
function removes the child from the namespace and decrements the
reference count.  It does not, however, guarantee to free the child
since the refcount may still be held.

Just call object_unparent() directly.

Suggested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
apic: Cleanup for QOM'ification

Do some cleanup, including:
1. Remove DO_UPCAST() for APICCommonState
2. Change DeviceState pointers from 'd' to 'dev', better to understand
3. Rename 'register_types' to specifically 'apic_common_register_types'

Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
apic: QOM'ify APIC

Convert 'init' function to QOM's 'realize' for apic, kvm/apic and
xen/xen_apic.

Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>