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>

This patch implements the PAPR specified Inter Virtual Machine Logical
LAN; that is the virtual hardware used by the Linux ibmveth driver.
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>

This patch implements the necessary infrastructure and hypercalls for
sPAPR's TCE (Translation Control Entry) IOMMU mechanism.  This is necessary
for all virtual IO devices which do DMA (i.e. nearly all of them).
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>

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: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch adds infrastructure to support interrupts from PAPR virtual IO
devices.  This includes correctly advertising those interrupts in the
device tree, and implementing the H_VIO_SIGNAL hypercall, used to
enable and disable individual device interrupts.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

PAPR defines an interrupt control architecture which is logically divided
into ICS (Interrupt Control Presentation, each unit is responsible for
presenting interrupts to a particular "interrupt server", i.e. CPU) and
ICS (Interrupt Control Source, each unit responsible for one or more
hardware interrupts as numbered globally across the system).  All PAPR
virtual IO devices expect to deliver interrupts via this mechanism.  In
Linux, this interrupt controller system is handled by the "xics" driver.

On pSeries systems, access to the interrupt controller is virtualized via
hypercalls and RTAS methods.  However, the virtualized interface is very
similar to the underlying interrupt controller hardware, and similar PICs
exist un-virtualized in some other systems.

This patch implements both the ICP and ICS sides of the PAPR interrupt
controller.  For now, only the hypercall virtualized interface is provided,
however it would be relatively straightforward to graft an emulated
register interface onto the underlying interrupt logic if we want to add
a machine with a hardware ICS/ICP system in the future.

There are some limitations in this implementation: it is assumed for now
that only one instance of the ICS exists, although a full xics system can
have several, each responsible for a different group of hardware irqs.
ICP/ICS can handle both level-sensitve (LSI) and message signalled (MSI)
interrupt inputs.  For now, this implementation supports only MSI
interrupts, since that is used by PAPR virtual IO devices.
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>

This patch adds several small utility hypercalls and RTAS methods to
the pSeries platform emulation.  Specifically:

* 'display-character' rtas call

This just prints a character to the console, it's occasionally used
for early debug of the OS.  The support includes a hack to make this
RTAS call respond on the normal token value present on real hardware,
since some early debugging tools just assume this value without
checking the device tree.

* 'get-time-of-day' rtas call

This one just takes the host real time, converts to the PAPR described
format and returns it to the guest.

* 'power-off' rtas call

This one shuts down the emulated system.

* H_DABR hypercall

On pSeries, the DABR debug register is usually a hypervisor resource
and virtualized through this hypercall.  If the hypercall is not
present, Linux will under some circumstances attempt to manipulate the
DABR directly which will fail on this emulated machine.

This stub implementation is enough to stop that behaviour, although it
doesn't actually implement the requested DABR operations as yet.
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>

On pSeries machines, operating systems can instantiate "RTAS" (Run-Time
Abstraction Services), a runtime component of the firmware which implements
a number of low-level, infrequently used operations.  On logical partitions
under a hypervisor, many of the RTAS functions require hypervisor
privilege.  For simplicity, therefore, hypervisor systems typically
implement the in-partition RTAS as just a tiny wrapper around a hypercall
which actually implements the various RTAS functions.

This patch implements such a hypercall based RTAS for our emulated pSeries
machine.  A tiny in-partition "firmware" calls a new hypercall, which
looks up available RTAS services in a table.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

On pSeries logical partitions, excepting the old POWER4-style full system
partitions, the guest does not have direct access to the hardware page
table.  Instead, the pagetable exists in hypervisor memory, and the guest
must manipulate it with hypercalls.

However, our current pSeries emulation more closely resembles the old
style where the guest must set up and handle the pagetables itself.  This
patch converts it to act like a modern partition.

This involves two things: first, the hash translation path is modified to
permit the has table to be stored externally to the emulated machine's
RAM.  The pSeries machine init code configures the CPUs to use this mode.

Secondly, we emulate the PAPR hypercalls for manipulating the external
hashed page table.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>