The core tcg/kvm code for ppc64 now has at least the outline
capability to support pagesizes beyond the standard 4k and 16MB.  The
CPUState is initialized with information advertising the available
pagesizes and their correct encodings, and under the right KVM setup
this will be populated with page sizes beyond the standard.

Obviously guests can't use the extra page sizes unless they know
they're present.  For the pseries machine, at least, there is a
defined method for conveying exactly this information, the
"ibm-segment-page-sizes" property in the guest device tree.

This patch generates this property using the supported page size
information that's already in the CPUState.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Allows us to use cpu_reset() in place of cpu_state_reset().
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NAlexander Graf <agraf@suse.de>

Needed for spapr_cpu_reset().
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NAlexander Graf <agraf@suse.de>

PAPR virtual IO (VIO) devices require a unique, but otherwise arbitrary,
"address" used as a token to the hypercalls which manipulate them.

Currently the pseries machine code does an ok job of allocating these
addresses when the legacy -net nic / -serial and so forth options are used
but will fail to allocate them properly when using -device.

Specifically, you can use -device if all addresses are explicitly assigned.
Without explicit assignment, only one VIO device of each type (network,
console, SCSI) will be assigned properly, any further ones will attempt
to take the same address leading to a fatal error.

This patch fixes the situation by adding a proper address allocator to the
VIO "bus" code.  This is used both by -device and the legacy options and
default devices.  Addresses can still be explicitly assigned with -device
options if desired.

This patch changes the (guest visible) numbering of VIO devices, but since
their addresses are discovered using the device tree and already differ
from the numbering found on existing PowerVM systems, this does not break
compatibility.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The pseries "xics" interrupt controller, like most interrupt
controllers can support both message (i.e. edge sensitive) interrupts
and level sensitive interrupts, but it needs to know which are which.

When I implemented the xics emulation for qemu, the only devices we
supported were the PAPR virtual IO devices.  These devices only use
message interrupts, so they were the only ones I implemented in xics.

Since then, however, we have added support for PCI devices, which use
level sensitive interrupts.  It turns out the message interrupt logic
still actually works most of the time for these, but there are
circumstances where we can lost interrupts due to the incorrect
interrupt logic.

This patch, therefore, implements the correct xics level-sensitive
interrupt logic.  The type of the interrupt is set when a device
allocates a new xics interrupt.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Scripted conversion:
  for file in hw/ppc*.[hc] hw/mpc8544_guts.c hw/spapr*.[hc] hw/virtex_ml507.c hw/xics.c; do
    sed -i "s/CPUState/CPUPPCState/g" $file
  done
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NAnthony Liguori <aliguori@us.ibm.com>

Frees the identifier cpu_reset for QOM CPUs (manual rename).

Don't hide the parameter type behind explicit casts, use static
functions with strongly typed argument to indirect.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>

Improve VGA selection logic, push check for device availabilty to vl.c.
Create the devices at board level unconditionally.

Remove now unused pci_try_create*() functions.

Make PCI VGA devices optional.
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Currently on the pseries machine the SLOF firmware is used normally,
but we bypass it when -kernel is specified.  Having these two

different boot paths can cause some confusion.

In particular at present we need to "probe" the (emulated) PCI bus and
produce device tree nodes for the PCI devices in qemu, for the -kernel
case.  In the SLOF case, it takes the device tree from qemu adds some
stuff to it then passes it on to the kernel.

It's been decided that a better approach is to always boot through
SLOF, even when using -kernel.  WIth this approach we can leave PCI
probing and device node creation to SLOF in all cases which removes a
bunch of code in qemu, and avoids iterating the PCI devices from the
machine specific init code which we're not supposed to do.

This patch changes qemu to always boot through SLOF, and not to create
PCI nodes.  Simultaneously it updates the included version of SLOF
(submodule and binary image) to one which supports (and requires) the
new approach.

The new SLOF version also includes a number of unrelated enhancements:
support for booting from virtio-pci devices and e1000, greatly
improved FCode support and many bugfixes.  It also makes SLOF ready to
be used even when specifying a kernel on the qemu command line.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently creating a memory region automatically registers it for
live migration.  This differs from other state (which is enumerated
in a VMStateDescription structure) and ties the live migration code
into the memory core.

Decouple the two by introducing a separate API, vmstate_register_ram(),
for registering a RAM block for migration.  Currently the same
implementation is reused, but later it can be moved into a separate list,
and registrations can be moved to VMStateDescription blocks.
Signed-off-by: NAvi Kivity <avi@redhat.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: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add NUMA specific properties to guest's device tree to boot a multi-node
guests. This patch adds the following properties:

ibm,associativity
ibm,architecture-vec-5
ibm,associativity-reference-points

With this, it becomes possible to use -numa option on pseries targets.
Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The SLOF firmware used on the pseries machine needs a reasonable amount of
(guest) RAM in order to run, so we have a check in the machine init
function to check that this is available.  However, SLOF runs in real mode
(MMU off) which means it can only actually access the RMA (Real Mode Area),
not all of RAM.  In many cases the RMA is the same as all RAM, but when
running with Book3S HV KVM on PowerPC 970, the RMA must be especially
allocated to be (host) physically contiguous.  In this case, the RMA size
is determined by what the host admin allocated at boot time, and will
usually be less than the whole guest RAM size.

This patch corrects the test to see if SLOF has enough memory for this
case.

In addition, more recent versions of SLOF that were committed earlier don't
need quite as much memory as earlier versions.  Therefore, this patch also
reduces the amount of RAM we require to run SLOF.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Since we added PCI support to the pseries machine, we include a qlist of
PCI host bridges in the sPAPREnvironment structure.  However this list
was never properly initialized it.  Somehow we got away with this until
some other recent change broke it, and we now segfault immediately on
startup.

This patch adds the required QLIST_INIT(), and while we're at it makes sure
we initialize the rest of the sPAPREnvironment structure to 0, to avoid
future nasty surprises.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds a PCI bus to the pseries machine.  This instantiates
the qemu generic PCI bus code, advertises a PCI host bridge in the
guest's device tree and implements the RTAS methods specified by PAPR
to access PCI config space.  It also sets up the memory regions we
need to provide windows into the PCI memory and IO space, and
advertises those to the guest.

However, because qemu can't yet emulate an IOMMU, which is mandatory on
pseries, PCI devices which use DMA (i.e. most of them) will not work with
this code alone.  Still, this is enough to support the virtio_pci device
(which probably _should_ use emulated PCI DMA, but is specced to use
direct hypervisor access to guest physical memory instead).

[agraf] remove typedef which could cause compile errors
Signed-off-by: NAlexey Kardashevskiy <aik@au1.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently, when KVM is enabled, the pseries machine checks if the host
CPU supports VMX, VSX and/or DFP instructions and advertises
accordingly in the guest device tree.  It does this regardless of what
CPU is selected on the command line.  On the other hand, when in TCG
mode, it never advertises any of these facilities, even basic VMX
(Altivec) which is supported in TCG.

Now that we have a -cpu host option for ppc, it is fairly
straightforward to fix both problems.  This patch changes the -cpu
host code to override the basic cpu spec derived from the PVR with
information queried from the host avout VMX, VSX and DFP capability.
The pseries code then uses the instruction availability advertised in
the cpu state to set the guest device tree correctly for both the KVM
and TCG cases.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Now that we've implemented -cpu host for ppc, this patch updates the
pseries machine to use the host cpu as the guest cpu by default when
running under KVM.  This is important because under KVM Book3S-HV the guest
cpu _cannot_ be of a different type to the host cpu (at the moment
KVM Book3S-HV will silently virtualize the host cpu instead of whatever was
requested, but in future it is likely to simply refuse to run the VM if
a cpu model other than the host's is requested).
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Sufficiently recent PAPR specifications define properties "ibm,vmx"
and "ibm,dfp" on the CPU node which advertise whether the VMX vector
extensions (or the later VSX version) and/or the Decimal Floating
Point operations from IBM's recent POWER CPUs are available.

Currently we do not put these in the guest device tree and the guest
kernel will consequently assume they are not available.  This is good,
because they are not supported under TCG.  VMX is similar enough to
Altivec that it might be trivial to support, but VSX and DFP would
both require significant work to support in TCG.

However, when running under kvm on a host which supports these
instructions, there's no reason not to let the guest use them.  This
patch, therefore, checks for the relevant support on the host CPU
and, if present, advertises them to the guest as well.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

At present, using the hypervisor aware Book3S-HV KVM will only work
with qemu on POWER7 CPUs.  PPC970 CPUs also have hypervisor
capability, but they lack the VRMA feature which makes assigning guest
memory easier.

In order to allow KVM Book3S-HV on PPC970, we need to specially
allocate the first chunk of guest memory (the "Real Mode Area" or
RMA), so that it is physically contiguous.

Sufficiently recent host kernels allow such contiguous RMAs to be
allocated, with a kvm capability advertising whether the feature is
available and/or necessary on this hardware.  This patch enables qemu
to use this support, thus allowing kvm acceleration of pseries qemu
machines on PPC970 hardware.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

---

agraf: fix to use memory api

Alex Graf has already made qemu support KVM for the pseries machine
when using the Book3S-PR KVM variant (which runs the guest in
usermode, emulating supervisor operations).  This code allows gets us
very close to also working with KVM Book3S-HV (using the hypervisor
capabilities of recent POWER CPUs).

This patch moves us another step towards Book3S-HV support by
correctly handling SMT (multithreaded) POWER CPUs.  There are two
parts to this:

 * Querying KVM to check SMT capability, and if present, adjusting the
   cpu numbers that qemu assigns to cause KVM to assign guest threads
   to cores in the right way (this isn't automatic, because the POWER
   HV support has a limitation that different threads on a single core
   cannot be in different guests at the same time).

 * Correctly informing the guest OS of the SMT thread to core mappings
   via the device tree.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Signed-off-by: NAvi Kivity <avi@redhat.com>

Paulo Bonzini changed the original spapr code, which manually assigned irq
numbers for each virtual device, to allocate them automatically from the
device initialization. That allowed spapr virtual devices to be constructed
with -device, which is a good start.  However, the way that patch worked
doesn't extend nicely for the future when we want to support devices other
than sPAPR VIO devices (e.g. virtio and PCI).

This patch rearranges the irq allocation to be global across the sPAPR
environment, so it can be used by other bus types as well.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds support for the H_REMOVE_BULK hypercall on the pseries
machine.  Strictly speaking this isn't necessarym since the kernel will
only attempt to use this if hcall-bulk is advertised in the device tree,
which previously it was not.

Adding this support may give a marginal performance increase, but more
importantly it reduces the differences between the emulated machine and
an existing PowerVM or kvm system, both of which already implement
hcall-bulk.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

For some time we've had a nicely defined macro with the filename for our
firmware image.  However we didn't actually use it in the place we're
supposed to.  This patch fixes it.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently our implementation of the H_ENTER hypercall, which inserts a
mapping in the hash page table assumes that only ordinary memory is ever
mapped, and only permits mapping attribute bits accordingly (WIMG==0010).

However, we intend to start adding emulated IO to the pseries platform
(and real IO with PCI passthrough on kvm) which means this simple test
will no longer suffice.

This patch extends the h_enter validation code to check if the given
address is a RAM address.  If it is it enforces WIMG==0010, otherwise
it assumes that it is an IO mapping and instead enforces WIMG=010x.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The interrupt controller presented in the device tree for the pseries
machine is manipulated by the guest only through hypervisor calls.  It
has no real or emulated registers for the guest to access.

However, it currently has a bogus 'reg' property advertising a register
window.  Moreover, this property has an invalid format, being a 32-bit
zero, when the #address-cells property on the root bus indicates that it
needs a 64-bit address.  Since the guest never attempts to manipulate
the node directly, it works, but it is ugly and can cause warnings when
manipulating the device tree in other tools (such as future firmware
versions).

This patch, therefore, corrects the problem by entirely removing the
interrupt-controller node's 'reg' property.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Future devices we will be adding to the pseries machine (e.g. PCI) will
need nodes in the device tree which explicitly reference the top-level
interrupt controller via interrupt-parent or interrupt-map properties.

In order to do this, the interrupt controller node needs an assigned
phandle.  This patch adds the appropriate property, in preparation.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

One of the things we can't fake on PPC is the timer speed. So
we need to extract the frequency information from the host and
put it back into the guest device tree.

Luckily, we already have functions for that from the non-pseries
targets, so all we need to do is to connect the dots and the guest
suddenly gets to know its real timer speeds.
Signed-off-by: NAlexander Graf <agraf@suse.de>

When running PR style KVM, we need to tell the kernel that we want
to run in PAPR mode now. This means that we need to pass some more
register information down and enable papr mode. We also need to align
the HTAB to htab_size boundary.

Using this patch, -M pseries works with kvm even on non-hv kvm
implementations, as long as the preceding kernel patches are in.
Signed-off-by: NAlexander Graf <agraf@suse.de>

---

v1 -> v2:

  - match on CONFIG_PSERIES

v2 -> v3:

  - remove HIOR pieces from PAPR patch (ABI breakage)

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: NPaolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

qemu_malloc/qemu_free no longer exist after this commit.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently the qemu pseries machine numbers its virtual serial devices
from 0.  However, existing pSeries machines running pHyp number them from
0x30000000.

In theory these indices are arbitrary, since everything necessary for the
kernel to find them is advertised in the device tree.  However the debian
installer, at least, incorrectly looks for a device named vty@30... to
determine whether to use the hypervisor console.

Therefore this patch moves the numbers we use to match the existing pHyp
practice, in order to workaround broken userspace apps of this type.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently, the qemu emulated pseries machine puts
"qemu,emulated-pSeries-LPAR" in the device tree's root level 'model'
property.  Unfortunately this confuses some installers and ybin, which
expect this to start with "IBM" on pSeries machines.  This patch addresses
this problem, making the property more closely resemble the pattern of
existing real hardware.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The original pSeries machine was limited to 32 CPUs, more or less
arbitrarily.  Particularly when we get SMT KVM guests it will be
pretty easy to exceed this.  Therefore, raise the max number of CPUs
in a pseries machine guest to 256.
Signed-off-by: NAnton Blanchard <anton@au1.ibm.com>
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.

However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.

Supplying a correct device tree is, in any case, part of the required
platform entry conditions.  Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback.  The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.

This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM.  It's a step in the right direction, though.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently the pseries machine init code builds up an array, envs, of
CPUState pointers for all the cpus in the system.  This is kind of
pointless, given the generic code already has a perfectly good linked list
of the cpus.

In addition, there are a number of places which assume that the cpu's
cpu_index field is equal to its index in this array.  This is true in
practice, because cpu_index values are just assigned sequentially, but
it's conceptually incorrect and may not always be true.

Therefore, this patch abolishes the envs array, and explicitly uses the
generic cpu linked list and cpu_index values throughout.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Currently, the emulated pSeries machine requires the use of the
-kernel parameter in order to explicitly load a guest kernel.  This
means booting from the virtual disk, cdrom or network is not possible.

This patch addresses this limitation by inserting a within-partition
firmware image (derived from the "SLOF" free Open Firmware project).
If -kernel is not specified, qemu will now load the SLOF image, which
has access to the qemu boot device list through the device tree, and
can boot from any of the usual virtual devices.

In order to support the new firmware, an extension to the emulated
machine/hypervisor is necessary.  Unlike Linux, which expects
multi-CPU entry to be handled kexec() style, the SLOF firmware expects
only one CPU to be active at entry, and to use a hypervisor RTAS
method to enable the other CPUs one by one.

This patch also implements this 'start-cpu' method, so that SLOF can
start the secondary CPUs and marshal them into the kexec() holding
pattern ready for entry into the guest OS.  Linux should, and in the
future might directly use the start-cpu method to enable initially
disabled CPUs, but for now it does require kexec() entry.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Shared-processor partitions are those where a CPU is time-sliced between
partitions, rather than being permanently dedicated to a single
partition.  qemu emulated partitions, since they are just scheduled with
the qemu user process, behave mostly like shared processor partitions.

In order to better support shared processor partitions (splpar), PAPR
defines the "VPA" (Virtual Processor Area), a shared memory communication
channel between the hypervisor and partitions.  There are also two
additional shared memory communication areas for specialized purposes
associated with the VPA.

A VPA is not essential for operating an splpar, though it can be necessary
for obtaining accurate performance measurements in the presence of
runtime partition switching.

Most importantly, however, the VPA is a prerequisite for PAPR's H_CEDE,
hypercall, which allows a partition OS to give up it's shared processor
timeslices to other partitions when idle.

This patch implements the VPA and H_CEDE hypercalls in qemu.  We don't
implement any of the more advanced statistics which can be communicated
through the VPA.  However, this is enough to make normal pSeries kernels
do an effective power-save idle on an emulated pSeries, significantly
reducing the host load of a qemu emulated pSeries running an idle guest OS.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch implements the infrastructure and hypercalls necessary for
the PAPR specified Virtual SCSI interface.  This is the normal method
for providing (virtual) disks to PAPR partitions.
Signed-off-by: NBen Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch implements the infrastructure and hypercalls necessary for the
PAPR specified CRQ (Command Request Queue) mechanism.  This general
request queueing system is used by many of the PAPR virtual IO devices,
including the virtual scsi adapter.
Signed-off-by: NBen Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>