Previously LPCR was registered for the 970 class which was wrong as
it does not have LPCR. Instead, HID4 is used which this patch registers.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Compared to PowerISA-compliant CPUs, 970 family has most of them plus
PMC7/8 which are only present on 970 but not on POWER5 and later CPUs.
Since we are changing SPRs for Book3s/970 families, let's add them too.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
MMCR0, MMCR1, MMCRA, PMC1..6, SIAR, SDAR are defined for 970 and PowerISA
CPUs. Since we are building common infrastructure for SPRs intialization
to share it between 970 and POWER5+/7/..., let's add missing SPRs to
the 970 family. Later rework of CPU class initialization will use those
for all PowerISA CPUs.
This adds new SPRs and enables writing to Uxxxx SPRs from supermode.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
Since we started adding "POWER" prefix to 64bit PMU SPRs, let's finish
the transition and fix MMCRA and define a supermode version of it.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This stops using 7xx common SPRs init function and adds separate set
of helpers for 970.
This does not copy ICTC SPR as neither 970 manual nor PowerISA mention it.
This defines 970/book3s PMU SPRs constants as they differs from the ones
used for 7XX.
This creates 2 helpers for PMU SPRs, one for supermode privileged SPRs and
one for user privileged SPRs as "sup" versions can be shared across
the family while "user" versions will behave different starting POWER8
(which will be addressed later).
This allows writing to Uxxxx SPRs from supermode. spr_write_ureg() is
implemented for this as a copy of already existing spr_read_ureg().
This allows writing to supervisor's SIAR - it used to be disabled
when gen_spr_7xx() was used.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This changes UCTRL SPR to read from its supermode copy.
This enables reading from UCTRL in user mode.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This splits one init_proc_970() into a set of small helpers. Later
init_proc_970() will be generalized and will call different set of helpers
depending on the current CPU class.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
The differences between classes were:
1. SLB size, was 32 for 970 and 64 for others, should be 64 for all;
2. check_pow() callback, HID0 format is the same so should be the same
0x01C00000 which means "deep nap", "doze" and "nap" bits set;
3. LPCR - 970 does not have it but 970MP had one (by mistake).
This fixes wrong differences and makes one 970 class.
This fixes wrong registration of LPCR which is not present on 970.
This defines HID0 bits and uses them in check_pow_970().
This does not copy MSR_SHV (Hypervisor State, HV) bit from 970FX to
970 class as we do not emulate hypervisor in QEMU anyway.
This does not remove check_pow_970FX now as it is still used by POWER5+
class, this will be addressed later.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
As defined in Linux kernel, PMC*, SIAR, MMCR0/1 have different numbers
for 32 and 64 bit POWERPC. We are going to support 64bit versions too so
let's rename 32bit ones to avoid confusion.
This is a mechanical patch so it does not fix obvious mistake with these
registers in POWER7 yet, this will be fixed later.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Fix a temporary variable leak detected in the bctar instruction:
Opcode 13 10 11 (4d910460) leaked temporaries
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Today we have a lot of conditional code in the SPE emulation depending on
whether we have 64bit GPRs or not.
Unfortunately the assumption that we can just recycle the 64bit GPR
implementation is wrong. Normal SPE implementations maintain the upper 32 bits
on all non-SPE instructions which then only modify the low 32 bits. However
all instructions we model that adhere to the normal SF based switching don't
care whether they operate on 32 or 64 bit registers and just always use the full
64 bits.
So let's remove that dubious SPE optimization and revert everything to the same
code path the 32bit target code was taking. That way we get rid of differences
between the two implementations, but will get a slight performance hit when
emulating SPE instructions.
This fixes SPE emulation with qemu-system-ppc64 for me.
Signed-off-by: Alexander Graf <agraf@suse.de>
PR KVM supports an ePAPR compliant hypercall interface in parallel to the
normal sPAPR one. Expose the ePAPR /hypervisor node and properties to the
guest so it can use it.
This enables magic page sharing on PR KVM with -M pseries.
However we had a few nasty bugs in the magic page implementation on vcpus
newer than 970 (p7, p8) that KVM now has workarounds for. It indicates that
it does have these workarounds through the PPC_FIXUP_HCALL capability.
To not expose broken guest kernels to issues on host kernels that don't
have the fixups in place, we don't expose working hypercall instructions
when the fixups are not available so that the guest can never active the
magic page.
Signed-off-by: Alexander Graf <agraf@suse.de>
New kvm versions expose a PPC_FIXUP_HCALL capability. Make it visible to
machine code so we can take decisions based on it.
Signed-off-by: Alexander Graf <agraf@suse.de>
The SPE emulation code wants to access the highest 32bits of a 64bit register
and uses the andi TCG instruction for that. Unfortunately it masked with the
wrong mask. Fix the mask to actually cover the upper 32 bits.
This fixes simple multiplication tests with SPE guests for me.
Signed-off-by: Alexander Graf <agraf@suse.de>
When we run 32bit guest CPUs (or 32bit guest code on 64bit CPUs) on
qemu-system-ppc64 the TLB lookup will use the full effective address
as pointer.
However, only the first 32bits are valid when MSR.CM = 0. Check for
that condition.
This makes QEMU boot an e500v2 guest with more than 1G of RAM for me.
Signed-off-by: Alexander Graf <agraf@suse.de>
Fix a typo in the ppce500_pci vmstate definition which meant that
we were migrating the struct pci_inbound using the vmstate for
pci_outbound. Fortunately the two structures have exactly the same
format at the moment (four uint32_ts) so this was harmless, and
we can correcting the typo without a migration compatibility
break because the vmstate name doesn't go out on the wire.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
The size and register information are encoded into the reserve_info field
of CPU state in the store conditional translation code. Specifically, the
size is shifted left by 5 bits (see target-ppc/translate.c gen_conditional_store).
The user-mode store conditional code erroneously extracts the size by ANDing
with a 4 bit mask; this breaks if size >= 16.
Eliminate the mask to make the extraction of size mirror its encoding.
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
The existing code does a check to ensure that a .bss region is properly
mmap'd. When additional mmap is required, the (guest) pages are also
validated. However, this code has a bug: when host page size is larger
than target page size, it is possible for the .bss pages to already be
(host) mapped but the guest .bss pages may not be valid.
The check to mmap additional space is separated from the flagging of the
target (guest) pages, thus ensuring that both aspects are done properly.
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Some modern tool chains use VSX instructions. Therefore attempt to enable the VSX MSR
bit by default, just like similar bits (FP, VEC, SPE, etc.).
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This allows running PPC64 little-endian in user mode if target is configured
that way. In PPC64 LE user mode we set MSR.LE during initialization.
Signed-off-by: Doug Kwan <dougkwan@google.com>
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Look at ELF header to determine ABI version on PPC64. This is required
for executing the first instruction correctly. Also print correct machine
name in uname() system call.
Signed-off-by: Doug Kwan <dougkwan@google.com>
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
A "mtspr SPRMMUCSR0, reg" always flushed TLB0,
because it passed the SPR number 0x3f4 to the flush routine.
But we want to flush either TLB0 or TBL1 depending on the GPR value.
Signed-off-by: Alex Zuepke <alexander.zuepke@hs-rm.de>
[agraf: change subject line, fix TCGv size mismatch]
Signed-off-by: Alexander Graf <agraf@suse.de>
This adds @bus_offset into sPAPRTCETable to tell where TCE table starts
from. It is set to 0 for emulated devices. Dynamic DMA windows will use
other offset.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
At the moment only 4K pages are supported by sPAPRTCETable. Since sPAPR
spec allows other page sizes and we are going to implement them, we need
page size to be configrable.
This adds @page_shift into sPAPRTCETable and replaces SPAPR_TCE_PAGE_SHIFT
with it where it is possible.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This removes window_size as it is basically a copy of nb_table
shifted by SPAPR_TCE_PAGE_SHIFT. As new dynamic DMA windows are
going to support windows as big as the entire RAM and this number
will be bigger that 32 capacity, we will have to do something
about @window_size anyway and removal seems to be the right way to go.
This removes dma_window_start/dma_window_size from sPAPRPHBState as
they are no longer used.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
qdev_init_nofail() was replaced by object_property_set_bool("realized")
all over the QEMU so do we.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
At the moment sPAPRPHBState contains a @tcet pointer to the only
TCE table. However sPAPR spec allows having more than one DMA window.
Since the TCE object is already a child of SPAPR PHB object, there is
no need to keep an additional pointer to it in sPAPRPHBState so remove it.
This changes the way sPAPRPHBState::reset performs reset of sPAPRTCETable
objects.
This changes the default DMA window properties calculation.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
Currently the default DMA window is represented by a single MemoryRegion.
However there can be more than just one window so we need
a "root" memory region to be separated from the actual DMA window(s).
This introduces a "root" IOMMU memory region and adds a subregion for
the default DMA 32bit window. Following patches will add other
subregion(s).
This initializes a default DMA window subregion size to the guest RAM
size as this window can be switched into "bypass" mode which implements
direct DMA mapping.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
The spapr-pci PHB initializes IOMMU for emulated devices only.
The upcoming VFIO support will do it different. However both emulated
and VFIO PHB types share most of the initialization code.
For the type specific things a new finish_realize() callback is
introduced.
This introduces sPAPRPHBClass derived from PCIHostBridgeClass and
adds the callback pointer.
This implements finish_realize() for emulated devices.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: Fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
Currently only single TCE entry per request is supported (H_PUT_TCE).
However PAPR+ specification allows multiple entry requests such as
H_PUT_TCE_INDIRECT and H_STUFF_TCE. Having less transitions to the host
kernel via ioctls, support of these calls can accelerate IOMMU operations.
This implements H_STUFF_TCE and H_PUT_TCE_INDIRECT.
This advertises "multi-tce" capability to the guest if the host kernel
supports it (KVM_CAP_SPAPR_MULTITCE) or guest is running in TCG mode.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
At the moment the "ibm,hypertas-functions" list is fixed. However some
calls should be listed there if they are supported by QEMU or the host
kernel.
This enables hyperrtas_prop to grow on stack by adding
a SPAPR_HYPERRTAS_ADD macro. "qemu,hypertas-functions" is converted as well.
The first user of this is going to be a "multi-tce" property.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
The timer registers on our KeyLargo macio emulation are read as byte reversed
from the big endian guest, so we better expose them endian reversed as well.
This fixes initial hickups of booting Mac OS X with -M mac99 for me.
Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
The macio IDE controller has some pretty nasty magic in its implementation to
allow for unaligned sector accesses. We used to handle these accesses
synchronously inside the IO callback handler.
However, the block infrastructure changed below our feet and now it's impossible
to call a synchronous block read/write from the aio callback handler of a
previous block access.
Work around that limitation by making the unaligned handling bits also go
through our asynchronous handler.
This fixes booting Mac OS X for me.
Reported-by: John Arbuckle <programmingkidx@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
The popcntb instruction is erroneously encoded with opcode extension (opc1,opc2) = (0x03,0x03).
Bits 21-30 of popcntb are 122 = 0b00011-0b11010 and therefore this should be encoded
as (opc1,opc2) = (0x1A, 0x03).
Signed-off-by: Tom Musta <tommusta@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
SPAPR IOMMU is a bus-less device and therefore its only ID in
migration stream is an instance id which is not reliable ID
as it depends on the command line parameters order. Since
libvirt may change the order, we need something better than that.
This removes VMSD descriptor from the class definitiion and
registers it with @liobn as an intance ID to let the destination
side find the right device to receive migration data.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
The host kernel implements a KVM_REG_PPC_ARCH_COMPAT register which
this uses to enable a compatibility mode if any chosen.
This sets the KVM_REG_PPC_ARCH_COMPAT register in KVM. ppc_set_compat()
signals the caller if the mode cannot be enabled by the host kernel.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix TCG compat setting]
Signed-off-by: Alexander Graf <agraf@suse.de>
Modern Linux kernels support last POWERPC CPUs so when a kernel boots,
in most cases it can find a matching cpu_spec in the kernel's cpu_specs
list. However if the kernel is quite old, it may be missing a definition
of the actual CPU. To provide an ability for old kernels to work on modern
hardware, a Processor Compatibility Mode has been introduced
by the PowerISA specification.
>From the hardware prospective, it is supported by the Processor
Compatibility Register (PCR) which is defined in PowerISA. The register
enables one of the compatibility modes (2.05/2.06/2.07).
Since PCR is a hypervisor privileged register and cannot be
directly accessed from the guest, the mode selection is done via
ibm,client-architecture-support (CAS) RTAS call using which the guest
specifies what "raw" and "architected" CPU versions it supports.
QEMU works out the best match, changes a "cpu-version" property of
every CPU and notifies the guest about the change by setting these
properties in the buffer passed as a response on a custom H_CAS hypercall.
This implements ibm,client-architecture-support parameters parsing
(now only for PVRs) and cooks the device tree diff with new values for
"cpu-version", "ibm,ppc-interrupt-server#s" and
"ibm,ppc-interrupt-server#s" properties.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This puts a limit to the number of threads per core based on the current
compatibility mode. Although PowerISA specs do not specify the maximum
threads per core number, the linux guest still expects that
PowerISA2.05-compatible CPU supports only 2 threads per core as this
is what POWER6 (2.05 compliant CPU) implements, the same is for
POWER7 (2.06, 4 threads) and POWER8 (2.07, 8 threads).
This calls spapr_fixup_cpu_smt_dt() with the maximum allowed number of
threads which affects ibm,ppc-interrupt-server#s and
ibm,ppc-interrupt-gserver#s properties.
The number of CPU nodesremains unchanged.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
In PPC code we usually use the "cs" name for a CPUState* variables
and "cpu" for PowerPCCPU. So let's change spapr_fixup_cpu_dt() to
use same rules as spapr_create_fdt_skel() does.
This adds missing nodes creation if they do not already exist in
the current device tree, this is going to be used from
the client-architecture-support handler.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
The PAPR+ specification defines a ibm,client-architecture-support (CAS)
RTAS call which purpose is to provide a negotiation mechanism for
the guest and the hypervisor to work out the best compatibility parameters.
During the negotiation process, the guest provides an array of various
options and capabilities which it supports, the hypervisor adjusts
the device tree and (optionally) reboots the guest.
At the moment the Linux guest calls CAS method at early boot so SLOF
gets called. SLOF allocates a memory buffer for the device tree changes
and calls a custom KVMPPC_H_CAS hypercall. QEMU parses the options,
composes a diff for the device tree, copies it to the buffer provided
by SLOF and returns to SLOF. SLOF updates the device tree and returns
control to the guest kernel. Only then the Linux guest parses the device
tree so it is possible to avoid unnecessary reboot in most cases.
The device tree diff is a header with an update format version
(defined as 1 in this patch) followed by a device tree with the properties
which require update.
If QEMU detects that it has to reboot the guest, it silently does so
as the guest expects reboot to happen because this is usual pHyp firmware
behavior.
This defines custom KVMPPC_H_CAS hypercall. The current SLOF already
has support for it.
This implements stub which returns very basic tree (root node,
no properties) to the guest.
As the return buffer does not contain any change, no change in behavior is
expected.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This introduces PCR mask for supported compatibility modes.
This will be used later by the ibm,client-architecture-support call.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
This adds basic support for the "compat" CPU option. By specifying
the compat property, the user can manually switch guest CPU mode from
"raw" to "architected".
This defines feature disable bits which are not used yet as, for example,
PowerISA 2.07 says if 2.06 mode is selected, the TM bit does not matter -
transactional memory (TM) will be disabled because 2.06 does not define
it at all. The same is true for VSX and 2.05 mode. So just setting a mode
must be ok.
This does not change the existing behavior as the actual compatibility
mode support is coming in next patches.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
The upcoming support of the "ibm,client-architecture-support"
reconfiguration call will be able to change dynamically the number
of threads per core (SMT mode). From the device tree prospective
this does not change the number of CPU nodes (as it is one node per
a CPU core) but affects content and size of the ibm,ppc-interrupt-server#s
and ibm,ppc-interrupt-gserver#s properties.
This moves ibm,ppc-interrupt-server#s and ibm,ppc-interrupt-gserver#s
out of the device tree skeleton.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
PowerISA defines a compatibility mode for server POWERPC CPUs which
is supported by the PCR special register which is hypervisor privileged.
To support this mode for guests, SPAPR defines a set of virtual PVRs,
one per PowerISA spec version. When a hypervisor needs a guest to work in
a compatibility mode, it puts a virtual PVR value into @cpu-version
property of a CPU node.
This introduces a "compat" CPU option which defines maximal compatibility
mode enabled. The supported modes are power6/power7/power8.
This does not change the existing behaviour, new property will be used
by next patches.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
When we trigger a system reset, the in-kernel openpic controller should also
get reset. This happens through a write to the GCR.RESET register which is
the same mechanism a guest would use to manually reset the device.
Signed-off-by: Alexander Graf <agraf@suse.de>
The openpic emulation code maintains an allowable-CPU's bitmap
("destmask") for each IRQ source which is calculated from the IDR
register value whenever the guest OS writes to it. However, if the
guest OS relies on the system to set the IDR register to a default
value at reset, and does not write IDR, then destmask does not get
updated, and interrupts do not get propagated to the guest.
Additionally, if an IRQ source is marked as critical, the source's
internal "output" and "nomask" fields are not correctly reset when the
PIC is reset.
Fix both these issues by calling write_IRQreg_idr from within
openpic_reset, instead of simply setting the IDR register to the
specified idr_reset value.
Signed-off-by: Paul Janzen <pcj@pauljanzen.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch moves the definition of openpic_reset after the various
register read/write functions. No functional change. It is in
preparation for using the register read/write functions in
openpic_reset.
Signed-off-by: Paul Janzen <pcj@pauljanzen.org>
Signed-off-by: Alexander Graf <agraf@suse.de>