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: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

There should be no need to look 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 when initializing
subclass::interface.  Thus, we need to pre-initialize the subclass's
parent_type field before calling type_initialize.  Apart from this, the
interface "types" should never be used and thus it is harmless to leave
them out of the hashtable.

Further, the interface types 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 patch fixes this as well.
Reported-by: NIgor Mammedov <imammedo@redhat.com>
Tested-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Tested-by: NNathan Rossi <nathan.rossi@xilinx.com>
Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Ask users of DEFINE_PROP_PTR() to set
cannot_instantiate_with_device_add_yet, or explain why it's not
needed.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com> (for ETRAX)
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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 18b6dade.

Cc: qemu-stable@nongnu.org
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Such devices have always been unavailable and omitted from the list of
available devices shown by device_add help.  Until commit 18b6dade
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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas 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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NAndreas 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 18b6dade.  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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The recent VSX patches broken compilation of QEMU when configurated
with --enable-debug, as it was treating "target long" TCG variables
as "i64" which is not true for 32bit targets.

This patch fixes all the places that the compiler has found to use
the correct variable type and if necessary manually cast.
Reported-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Patch queue for s390 - 2013-12-18

This covers mostly minor bug fixes and implements the SIGP START
hypercall which allows to start a remote CPU without changing its
state.

Cornelia Huck (1):
      s390x/kvm: Fix diagnose handling.

Thomas Huth (7):
      s390x/kvm: Removed duplicated SIGP defines
      s390x/kvm: Removed s390_store_status stub
      s390x/kvm: Fix coding style in handle_sigp()
      s390x/kvm: Implemented SIGP START
      s390x/kvm: Simplified the calculation of the SIGP order code
      s390x/kvm: Fixed condition code for unknown SIGP orders
      s390x/ioinst: CHSC has to set a condition code

* tag 'signed-s390-for-upstream' of git://github.com/agraf/qemu:
  s390x/ioinst: CHSC has to set a condition code
  s390x/kvm: Fixed condition code for unknown SIGP orders
  s390x/kvm: Simplified the calculation of the SIGP order code
  s390x/kvm: Implemented SIGP START
  s390x/kvm: Fix coding style in handle_sigp()
  s390x/kvm: Removed s390_store_status stub
  s390x/kvm: Removed duplicated SIGP defines
  s390x/kvm: Fix diagnose handling.

Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

The comments apply to 8-bit stores, not 8-byte stores.
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Patch queue for ppc - 2013-12-20

Alexander Graf (3):
      PPC: Use default pci bus name for grackle and heathrow
      roms: Flush icache when writing roms to guest memory
      PPC: Add VSX to hflags

Alexey Kardashevskiy (5):
      powerpc: add PVR mask support
      target-ppc: move POWER7+ to a separate family
      spapr-rtas: replace return code constants with macros
      spapr-rtas: add ibm, (get|set)-system-parameter
      spapr: make sure RMA is in first mode of first memory node

Greg Kurz (1):
      target-ppc: add stubs for KVM breakpoints

Paolo Bonzini (1):
      spapr: tie spapr-nvram to -pflash

Paul Mackerras (1):
      spapr: limit numa memory regions by ram size

Peter Crosthwaite (2):
      device_tree: s/qemu_devtree/qemu_fdt globally
      device_tree: qemu_fdt_setprop: Rename val_array arg

Tom Musta (19):
      Declare and Enable VSX
      Add MSR VSX and Associated Exception
      Add VSX Instruction Decoders
      Add VSR to Global Registers
      Add lxvd2x
      Add stxvd2x
      Add xxpermdi
      Add lxsdx
      Add lxvdsx
      Add lxvw4x
      Add stxsdx
      Add stxvw4x
      Add VSX Scalar Move Instructions
      Add VSX Vector Move Instructions
      Add Power7 VSX Logical Instructions
      Add xxmrgh/xxmrgl
      Add xxsel
      Add xxspltw
      Add xxsldwi

* agraf/tags/signed-ppc-for-upstream: (32 commits)
  spapr: limit numa memory regions by ram size
  spapr: make sure RMA is in first mode of first memory node
  device_tree: qemu_fdt_setprop: Rename val_array arg
  device_tree: s/qemu_devtree/qemu_fdt globally
  PPC: Add VSX to hflags
  Add xxsldwi
  Add xxspltw
  Add xxsel
  Add xxmrgh/xxmrgl
  Add Power7 VSX Logical Instructions
  Add VSX Vector Move Instructions
  Add VSX Scalar Move Instructions
  roms: Flush icache when writing roms to guest memory
  spapr: tie spapr-nvram to -pflash
  PPC: Use default pci bus name for grackle and heathrow
  spapr-rtas: add ibm, (get|set)-system-parameter
  spapr-rtas: replace return code constants with macros
  target-ppc: move POWER7+ to a separate family
  Add stxvw4x
  Add stxsdx
  ...

This makes sure that all NUMA memory blocks reside within RAM or
have zero length.
Reviewed-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The SPAPR specification says that the RMA starts at the LPAR's logical
address 0 and is the first logical memory block reported in
the LPAR’s device tree.

So SLOF only maps the first block and that block needs to span
the full RMA.

This makes sure that the RMA area is where SLOF expects it.
Reviewed-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Looking at the implementation, this doesn't really have a lot to do
with arrays. Its just a pointer to a buffer and is passed through
to the wrapped fn (qemu_fdt_setprop) unchanged. So rename to make it
consistent with libfdt, which in the wrapped function just calls it
"val".
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The qemu_devtree API is a wrapper around the fdt_ set of APIs.
Rename accordingly.
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
[agraf: also convert hw/arm/virt.c]
Signed-off-by: NAlexander Graf <agraf@suse.de>

We generate different code depending on whether MSR_VSX is set or
clear, so it needs to be part of our hflags too which indicate whether
we're still in the same translation block cache bucket.
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the VSX Shift Left Double by Word Immediate
(xxsldwi) instruction.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the VSX Splat Word (xxsplatw) instruction.

This is the first instruction to use the UIM immediate field
and consequently a decoder is also added.

V2: reworked implementation per Richard Henderson's comments.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the VSX Select (xxsel) instruction.

The xxsel instruction has four VSR operands.  Thus the xC
instruction decoder is added.

The xxsel instruction is massively overloaded in the opcode
table since only bits 26 and 27 are opcode bits.  This
overloading is done in matrix fashion with two macros
(GEN_XXSEL_ROW and GEN_XX_SEL).

V2: (1) eliminated unecessary XXSEL macro  (2) tighter implementation
using tcg_gen_andc_i64.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the VSX Merge High Word and VSX Merge Low Word
instructions.

V2: Now implemented using deposit (per Richard Henderson's comment)
Signed-off-by: NTom Musta <tommusta@gmail.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the VSX logical instructions that are defined
by the Version 2.06 Power ISA (aka Power7):

   - xxland
   - xxlandc
   - xxlor
   - xxlxor
   - xxlnor
Signed-off-by: NTom Musta <tommusta@gmail.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the vector move instructions:

  - xvabsdp - Vector Absolute Value Double-Precision
  - xvnabsdp - Vector Negative Absolute Value Double-Precision
  - xvnegdp - Vector Negate Double-Precision
  - xvcpsgndp - Vector Copy Sign Double-Precision
  - xvabssp - Vector Absolute Value Single-Precision
  - xvnabssp - Vector Negative Absolute Value Single-Precision
  - xvnegsp - Vector Negate Single-Precision
  - xvcpsgnsp - Vector Copy Sign Single-Precision

V3: Per Paolo Bonzini's suggestion, used a temporary for the
sign mask and andc.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds the VSX scalar move instructions:

  - xsabsdp (Scalar Absolute Value Double-Precision)
  - xsnabspd (Scalar Negative Absolute Value Double-Precision)
  - xsnegdp (Scalar Negate Double-Precision)
  - xscpsgndp (Scalar Copy Sign Double-Precision)

A common generator macro (VSX_SCALAR_MOVE) is added since these
instructions vary only slightly from each other.

Macros to support VSX XX2 and XX3 form opcodes are also added.
These macros handle the overloading of "opcode 2" space (instruction
bits 26:30) caused by AX and BX bits (29 and 30, respectively).

V3: Per feedback from Paolo Bonzini, moved the sign mask into a
temporary and used andc.
Signed-off-by: NTom Musta <tommusta@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

We use the rom infrastructure to write firmware and/or initial kernel
blobs into guest address space. So we're basically emulating the cache
off phase on very early system bootup.

That phase is usually responsible for clearing the instruction cache for
anything it writes into cachable memory, to ensure that after reboot we
don't happen to execute stale bits from the instruction cache.

So we need to invalidate the icache every time we write a rom into guest
address space. We do not need to do this for every DMA since the guest
expects it has to flush the icache manually in that case.

This fixes random reboot issues on e5500 (booke ppc) for me.
Signed-off-by: NAlexander Graf <agraf@suse.de>

spapr-nvram's drive property is currently connected to a non-existent
"-machine nvram=<drivename>" option.  Instead, tie it to -pflash like
other non-volatile RAM devices.  This provides the following possibilities
for adding a backend for the sPAPR non-volatile RAM:

* -pflash filename

* -drive if=pflash,file=filename,format=raw,...

* -drive if=none,file=filename,format=raw,id=foo,... -global spapr-nvram.drive=foo
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

There's no good reason to call our bus "pci" rather than let the default
bus name take over ("pci.0").

The big downside to calling it different from anyone else is that tools
that pass -device get confused. They are looking for a bus "pci.0" rather
than "pci".

To make life easier for everyone, let's just drop the name override.
Signed-off-by: NAlexander Graf <agraf@suse.de>

This adds very basic handlers for ibm,get-system-parameter and
ibm,set-system-parameter RTAS calls.

The only parameter handled at the moment is
"platform-processor-diagnostics-run-mode" which is always disabled and
does not support changing. This is expected to make
"ppc64_cpu --run-mode=1" happy.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
[agraf: s/papameter/parameter/g]
Signed-off-by: NAlexander Graf <agraf@suse.de>

Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>

So far POWER7+ was a part of POWER7 family. However it has a different
PVR base value so in order to support PVR masks, it needs a separate
family class.

This adds a new family class, PVR base and mask values and moves
Power7+ v2.1 CPU to a new family. The class init function is copied
from the POWER7 family.

This defines a firmware name for the new family as "PowerPC,POWER7+"
instead of previously used "PowerPC,POWER7" from the POWER7 family.
The reason for that is that the Sapphire firmware (a h0st firmware)
uses "PowerPC,POWER7+" already and since no specification defines
exactly the CPU nodes naming in the device tree, we better stay
in sync with the host firmware.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlexander Graf <agraf@suse.de>