2016-01-26 19:16:58 +01:00
|
|
|
#include "qemu/osdep.h"
|
2019-11-29 05:00:58 +01:00
|
|
|
#include "qemu/cutils.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 09:01:28 +01:00
|
|
|
#include "qapi/error.h"
|
2017-01-10 11:59:55 +01:00
|
|
|
#include "sysemu/hw_accel.h"
|
2019-08-12 07:23:59 +02:00
|
|
|
#include "sysemu/runstate.h"
|
2015-12-15 13:16:16 +01:00
|
|
|
#include "qemu/log.h"
|
Include qemu/main-loop.h less
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h,
qemu/thread.h, qemu/timer.h, and a few more.
Include qemu/main-loop.h only where it's needed. Touching it now
recompiles only some 1700 objects. For block/aio.h and
qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the
others, they shrink only slightly.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190812052359.30071-21-armbru@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-12 07:23:50 +02:00
|
|
|
#include "qemu/main-loop.h"
|
2019-05-23 16:35:07 +02:00
|
|
|
#include "qemu/module.h"
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
#include "qemu/error-report.h"
|
2016-03-15 13:18:37 +01:00
|
|
|
#include "exec/exec-all.h"
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
#include "helper_regs.h"
|
2013-02-05 17:06:20 +01:00
|
|
|
#include "hw/ppc/spapr.h"
|
2018-06-13 08:22:18 +02:00
|
|
|
#include "hw/ppc/spapr_cpu_core.h"
|
2013-03-12 01:31:18 +01:00
|
|
|
#include "mmu-hash64.h"
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
#include "cpu-models.h"
|
|
|
|
#include "trace.h"
|
|
|
|
#include "kvm_ppc.h"
|
2019-11-29 05:00:58 +01:00
|
|
|
#include "hw/ppc/fdt.h"
|
2016-10-25 06:47:28 +02:00
|
|
|
#include "hw/ppc/spapr_ovec.h"
|
2021-09-20 19:49:44 +02:00
|
|
|
#include "hw/ppc/spapr_numa.h"
|
2017-03-20 00:46:46 +01:00
|
|
|
#include "mmu-book3s-v3.h"
|
2018-04-23 18:51:16 +02:00
|
|
|
#include "hw/mem/memory-device.h"
|
2011-04-01 06:15:22 +02:00
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
bool is_ram_address(SpaprMachineState *spapr, hwaddr addr)
|
2016-01-21 04:48:43 +01:00
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
2018-04-23 18:51:23 +02:00
|
|
|
DeviceMemoryState *dms = machine->device_memory;
|
2016-01-21 04:48:43 +01:00
|
|
|
|
|
|
|
if (addr < machine->ram_size) {
|
|
|
|
return true;
|
|
|
|
}
|
2018-04-23 18:51:23 +02:00
|
|
|
if ((addr >= dms->base)
|
|
|
|
&& ((addr - dms->base) < memory_region_size(&dms->mr))) {
|
2016-01-21 04:48:43 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-07-12 09:56:55 +02:00
|
|
|
/* Convert a return code from the KVM ioctl()s implementing resize HPT
|
|
|
|
* into a PAPR hypercall return code */
|
|
|
|
static target_ulong resize_hpt_convert_rc(int ret)
|
|
|
|
{
|
|
|
|
if (ret >= 100000) {
|
|
|
|
return H_LONG_BUSY_ORDER_100_SEC;
|
|
|
|
} else if (ret >= 10000) {
|
|
|
|
return H_LONG_BUSY_ORDER_10_SEC;
|
|
|
|
} else if (ret >= 1000) {
|
|
|
|
return H_LONG_BUSY_ORDER_1_SEC;
|
|
|
|
} else if (ret >= 100) {
|
|
|
|
return H_LONG_BUSY_ORDER_100_MSEC;
|
|
|
|
} else if (ret >= 10) {
|
|
|
|
return H_LONG_BUSY_ORDER_10_MSEC;
|
|
|
|
} else if (ret > 0) {
|
|
|
|
return H_LONG_BUSY_ORDER_1_MSEC;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (ret) {
|
|
|
|
case 0:
|
|
|
|
return H_SUCCESS;
|
|
|
|
case -EPERM:
|
|
|
|
return H_AUTHORITY;
|
|
|
|
case -EINVAL:
|
|
|
|
return H_PARAMETER;
|
|
|
|
case -ENXIO:
|
|
|
|
return H_CLOSED;
|
|
|
|
case -ENOSPC:
|
|
|
|
return H_PTEG_FULL;
|
|
|
|
case -EBUSY:
|
|
|
|
return H_BUSY;
|
|
|
|
case -ENOMEM:
|
|
|
|
return H_NO_MEM;
|
|
|
|
default:
|
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-12 07:46:11 +02:00
|
|
|
static target_ulong h_resize_hpt_prepare(PowerPCCPU *cpu,
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineState *spapr,
|
2017-05-12 07:46:11 +02:00
|
|
|
target_ulong opcode,
|
|
|
|
target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong flags = args[0];
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
int shift = args[1];
|
2017-10-10 15:16:57 +02:00
|
|
|
uint64_t current_ram_size;
|
2017-07-12 09:56:55 +02:00
|
|
|
int rc;
|
2017-05-12 07:46:11 +02:00
|
|
|
|
|
|
|
if (spapr->resize_hpt == SPAPR_RESIZE_HPT_DISABLED) {
|
|
|
|
return H_AUTHORITY;
|
|
|
|
}
|
|
|
|
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
if (!spapr->htab_shift) {
|
|
|
|
/* Radix guest, no HPT */
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
}
|
|
|
|
|
2017-05-12 07:46:11 +02:00
|
|
|
trace_spapr_h_resize_hpt_prepare(flags, shift);
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
|
|
|
|
if (flags != 0) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (shift && ((shift < 18) || (shift > 46))) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2017-10-10 15:16:57 +02:00
|
|
|
current_ram_size = MACHINE(spapr)->ram_size + get_plugged_memory_size();
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
|
|
|
|
/* We only allow the guest to allocate an HPT one order above what
|
|
|
|
* we'd normally give them (to stop a small guest claiming a huge
|
|
|
|
* chunk of resources in the HPT */
|
|
|
|
if (shift > (spapr_hpt_shift_for_ramsize(current_ram_size) + 1)) {
|
|
|
|
return H_RESOURCE;
|
|
|
|
}
|
|
|
|
|
2017-07-12 09:56:55 +02:00
|
|
|
rc = kvmppc_resize_hpt_prepare(cpu, flags, shift);
|
|
|
|
if (rc != -ENOSYS) {
|
|
|
|
return resize_hpt_convert_rc(rc);
|
|
|
|
}
|
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
if (kvm_enabled()) {
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
return softmmu_resize_hpt_prepare(cpu, spapr, shift);
|
2017-05-12 07:46:11 +02:00
|
|
|
}
|
|
|
|
|
2017-09-25 13:00:02 +02:00
|
|
|
static void do_push_sregs_to_kvm_pr(CPUState *cs, run_on_cpu_data data)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
cpu_synchronize_state(cs);
|
|
|
|
|
|
|
|
ret = kvmppc_put_books_sregs(POWERPC_CPU(cs));
|
|
|
|
if (ret < 0) {
|
|
|
|
error_report("failed to push sregs to KVM: %s", strerror(-ret));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
void push_sregs_to_kvm_pr(SpaprMachineState *spapr)
|
2017-09-25 13:00:02 +02:00
|
|
|
{
|
|
|
|
CPUState *cs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a hack for the benefit of KVM PR - it abuses the SDR1
|
|
|
|
* slot in kvm_sregs to communicate the userspace address of the
|
|
|
|
* HPT
|
|
|
|
*/
|
|
|
|
if (!kvm_enabled() || !spapr->htab) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
run_on_cpu(cs, do_push_sregs_to_kvm_pr, RUN_ON_CPU_NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-12 07:46:11 +02:00
|
|
|
static target_ulong h_resize_hpt_commit(PowerPCCPU *cpu,
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineState *spapr,
|
2017-05-12 07:46:11 +02:00
|
|
|
target_ulong opcode,
|
|
|
|
target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong flags = args[0];
|
|
|
|
target_ulong shift = args[1];
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
int rc;
|
2017-05-12 07:46:11 +02:00
|
|
|
|
|
|
|
if (spapr->resize_hpt == SPAPR_RESIZE_HPT_DISABLED) {
|
|
|
|
return H_AUTHORITY;
|
|
|
|
}
|
|
|
|
|
2018-02-13 18:37:16 +01:00
|
|
|
if (!spapr->htab_shift) {
|
|
|
|
/* Radix guest, no HPT */
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
}
|
|
|
|
|
2017-05-12 07:46:11 +02:00
|
|
|
trace_spapr_h_resize_hpt_commit(flags, shift);
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
|
2017-07-12 09:56:55 +02:00
|
|
|
rc = kvmppc_resize_hpt_commit(cpu, flags, shift);
|
|
|
|
if (rc != -ENOSYS) {
|
2018-02-13 18:37:16 +01:00
|
|
|
rc = resize_hpt_convert_rc(rc);
|
|
|
|
if (rc == H_SUCCESS) {
|
|
|
|
/* Need to set the new htab_shift in the machine state */
|
|
|
|
spapr->htab_shift = shift;
|
|
|
|
}
|
|
|
|
return rc;
|
2017-07-12 09:56:55 +02:00
|
|
|
}
|
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
return H_HARDWARE;
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
}
|
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
return softmmu_resize_hpt_commit(cpu, spapr, flags, shift);
|
|
|
|
}
|
pseries: Implement HPT resizing
This patch implements hypercalls allowing a PAPR guest to resize its own
hash page table. This will eventually allow for more flexible memory
hotplug.
The implementation is partially asynchronous, handled in a special thread
running the hpt_prepare_thread() function. The state of a pending resize
is stored in SPAPR_MACHINE->pending_hpt.
The H_RESIZE_HPT_PREPARE hypercall will kick off creation of a new HPT, or,
if one is already in progress, monitor it for completion. If there is an
existing HPT resize in progress that doesn't match the size specified in
the call, it will cancel it, replacing it with a new one matching the
given size.
The H_RESIZE_HPT_COMMIT completes transition to a resized HPT, and can only
be called successfully once H_RESIZE_HPT_PREPARE has successfully
completed initialization of a new HPT. The guest must ensure that there
are no concurrent accesses to the existing HPT while this is called (this
effectively means stop_machine() for Linux guests).
For now H_RESIZE_HPT_COMMIT goes through the whole old HPT, rehashing each
HPTE into the new HPT. This can have quite high latency, but it seems to
be of the order of typical migration downtime latencies for HPTs of size
up to ~2GiB (which would be used in a 256GiB guest).
In future we probably want to move more of the rehashing to the "prepare"
phase, by having H_ENTER and other hcalls update both current and
pending HPTs. That's a project for another day, but should be possible
without any changes to the guest interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-05-12 07:46:49 +02:00
|
|
|
|
|
|
|
|
2017-05-12 07:46:11 +02:00
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_set_sprg0(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2016-02-11 13:47:18 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
cpu_synchronize_state(CPU(cpu));
|
|
|
|
cpu->env.spr[SPR_SPRG0] = args[0];
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_set_dabr(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2011-04-01 06:15:24 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
2021-05-07 18:41:46 +02:00
|
|
|
if (!ppc_has_spr(cpu, SPR_DABR)) {
|
2016-02-11 13:47:19 +01:00
|
|
|
return H_HARDWARE; /* DABR register not available */
|
|
|
|
}
|
|
|
|
cpu_synchronize_state(CPU(cpu));
|
|
|
|
|
2021-05-07 18:41:46 +02:00
|
|
|
if (ppc_has_spr(cpu, SPR_DABRX)) {
|
2016-02-11 13:47:19 +01:00
|
|
|
cpu->env.spr[SPR_DABRX] = 0x3; /* Use Problem and Privileged state */
|
|
|
|
} else if (!(args[0] & 0x4)) { /* Breakpoint Translation set? */
|
|
|
|
return H_RESERVED_DABR;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpu->env.spr[SPR_DABR] = args[0];
|
|
|
|
return H_SUCCESS;
|
2011-04-01 06:15:24 +02:00
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_set_xdabr(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2016-02-11 13:47:20 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong dabrx = args[1];
|
|
|
|
|
2021-05-07 18:41:46 +02:00
|
|
|
if (!ppc_has_spr(cpu, SPR_DABR) || !ppc_has_spr(cpu, SPR_DABRX)) {
|
2016-02-11 13:47:20 +01:00
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((dabrx & ~0xfULL) != 0 || (dabrx & H_DABRX_HYPERVISOR) != 0
|
|
|
|
|| (dabrx & (H_DABRX_KERNEL | H_DABRX_USER)) == 0) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpu_synchronize_state(CPU(cpu));
|
|
|
|
cpu->env.spr[SPR_DABRX] = dabrx;
|
|
|
|
cpu->env.spr[SPR_DABR] = args[0];
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_page_init(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2016-02-18 10:15:54 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong flags = args[0];
|
|
|
|
hwaddr dst = args[1];
|
|
|
|
hwaddr src = args[2];
|
|
|
|
hwaddr len = TARGET_PAGE_SIZE;
|
|
|
|
uint8_t *pdst, *psrc;
|
|
|
|
target_long ret = H_SUCCESS;
|
|
|
|
|
|
|
|
if (flags & ~(H_ICACHE_SYNCHRONIZE | H_ICACHE_INVALIDATE
|
|
|
|
| H_COPY_PAGE | H_ZERO_PAGE)) {
|
|
|
|
qemu_log_mask(LOG_UNIMP, "h_page_init: Bad flags (" TARGET_FMT_lx "\n",
|
|
|
|
flags);
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Map-in destination */
|
|
|
|
if (!is_ram_address(spapr, dst) || (dst & ~TARGET_PAGE_MASK) != 0) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
2020-02-19 20:20:42 +01:00
|
|
|
pdst = cpu_physical_memory_map(dst, &len, true);
|
2016-02-18 10:15:54 +01:00
|
|
|
if (!pdst || len != TARGET_PAGE_SIZE) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (flags & H_COPY_PAGE) {
|
|
|
|
/* Map-in source, copy to destination, and unmap source again */
|
|
|
|
if (!is_ram_address(spapr, src) || (src & ~TARGET_PAGE_MASK) != 0) {
|
|
|
|
ret = H_PARAMETER;
|
|
|
|
goto unmap_out;
|
|
|
|
}
|
2020-02-19 20:20:42 +01:00
|
|
|
psrc = cpu_physical_memory_map(src, &len, false);
|
2016-02-18 10:15:54 +01:00
|
|
|
if (!psrc || len != TARGET_PAGE_SIZE) {
|
|
|
|
ret = H_PARAMETER;
|
|
|
|
goto unmap_out;
|
|
|
|
}
|
|
|
|
memcpy(pdst, psrc, len);
|
|
|
|
cpu_physical_memory_unmap(psrc, len, 0, len);
|
|
|
|
} else if (flags & H_ZERO_PAGE) {
|
|
|
|
memset(pdst, 0, len); /* Just clear the destination page */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kvm_enabled() && (flags & H_ICACHE_SYNCHRONIZE) != 0) {
|
|
|
|
kvmppc_dcbst_range(cpu, pdst, len);
|
|
|
|
}
|
|
|
|
if (flags & (H_ICACHE_SYNCHRONIZE | H_ICACHE_INVALIDATE)) {
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
kvmppc_icbi_range(cpu, pdst, len);
|
|
|
|
} else {
|
|
|
|
tb_flush(CPU(cpu));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unmap_out:
|
|
|
|
cpu_physical_memory_unmap(pdst, TARGET_PAGE_SIZE, 1, len);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
#define FLAGS_REGISTER_VPA 0x0000200000000000ULL
|
|
|
|
#define FLAGS_REGISTER_DTL 0x0000400000000000ULL
|
|
|
|
#define FLAGS_REGISTER_SLBSHADOW 0x0000600000000000ULL
|
|
|
|
#define FLAGS_DEREGISTER_VPA 0x0000a00000000000ULL
|
|
|
|
#define FLAGS_DEREGISTER_DTL 0x0000c00000000000ULL
|
|
|
|
#define FLAGS_DEREGISTER_SLBSHADOW 0x0000e00000000000ULL
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
static target_ulong register_vpa(PowerPCCPU *cpu, target_ulong vpa)
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
{
|
2018-06-13 08:22:18 +02:00
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
uint16_t size;
|
|
|
|
uint8_t tmp;
|
|
|
|
|
|
|
|
if (vpa == 0) {
|
|
|
|
hcall_dprintf("Can't cope with registering a VPA at logical 0\n");
|
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vpa % env->dcache_line_size) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
/* FIXME: bounds check the address */
|
|
|
|
|
2013-12-17 05:33:56 +01:00
|
|
|
size = lduw_be_phys(cs->as, vpa + 0x4);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
|
|
|
if (size < VPA_MIN_SIZE) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* VPA is not allowed to cross a page boundary */
|
|
|
|
if ((vpa / 4096) != ((vpa + size - 1) / 4096)) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
spapr_cpu->vpa_addr = vpa;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
tmp = ldub_phys(cs->as, spapr_cpu->vpa_addr + VPA_SHARED_PROC_OFFSET);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
tmp |= VPA_SHARED_PROC_VAL;
|
2018-06-13 08:22:18 +02:00
|
|
|
stb_phys(cs->as, spapr_cpu->vpa_addr + VPA_SHARED_PROC_OFFSET, tmp);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
static target_ulong deregister_vpa(PowerPCCPU *cpu, target_ulong vpa)
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
2018-06-13 08:22:18 +02:00
|
|
|
|
|
|
|
if (spapr_cpu->slb_shadow_addr) {
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_RESOURCE;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
if (spapr_cpu->dtl_addr) {
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_RESOURCE;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
spapr_cpu->vpa_addr = 0;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
static target_ulong register_slb_shadow(PowerPCCPU *cpu, target_ulong addr)
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
uint32_t size;
|
|
|
|
|
|
|
|
if (addr == 0) {
|
|
|
|
hcall_dprintf("Can't cope with SLB shadow at logical 0\n");
|
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
size = ldl_be_phys(CPU(cpu)->as, addr + 0x4);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
if (size < 0x8) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((addr / 4096) != ((addr + size - 1) / 4096)) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
if (!spapr_cpu->vpa_addr) {
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_RESOURCE;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
spapr_cpu->slb_shadow_addr = addr;
|
|
|
|
spapr_cpu->slb_shadow_size = size;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
static target_ulong deregister_slb_shadow(PowerPCCPU *cpu, target_ulong addr)
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
2018-06-13 08:22:18 +02:00
|
|
|
|
|
|
|
spapr_cpu->slb_shadow_addr = 0;
|
|
|
|
spapr_cpu->slb_shadow_size = 0;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
static target_ulong register_dtl(PowerPCCPU *cpu, target_ulong addr)
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
uint32_t size;
|
|
|
|
|
|
|
|
if (addr == 0) {
|
|
|
|
hcall_dprintf("Can't cope with DTL at logical 0\n");
|
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
size = ldl_be_phys(CPU(cpu)->as, addr + 0x4);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
|
|
|
if (size < 48) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
if (!spapr_cpu->vpa_addr) {
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_RESOURCE;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
spapr_cpu->dtl_addr = addr;
|
|
|
|
spapr_cpu->dtl_size = size;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-06-13 08:22:18 +02:00
|
|
|
static target_ulong deregister_dtl(PowerPCCPU *cpu, target_ulong addr)
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
2018-06-13 08:22:18 +02:00
|
|
|
|
|
|
|
spapr_cpu->dtl_addr = 0;
|
|
|
|
spapr_cpu->dtl_size = 0;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_register_vpa(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong flags = args[0];
|
|
|
|
target_ulong procno = args[1];
|
|
|
|
target_ulong vpa = args[2];
|
|
|
|
target_ulong ret = H_PARAMETER;
|
2014-02-01 15:45:52 +01:00
|
|
|
PowerPCCPU *tcpu;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
2017-08-09 07:38:56 +02:00
|
|
|
tcpu = spapr_find_cpu(procno);
|
2013-02-15 16:43:08 +01:00
|
|
|
if (!tcpu) {
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (flags) {
|
|
|
|
case FLAGS_REGISTER_VPA:
|
2018-06-13 08:22:18 +02:00
|
|
|
ret = register_vpa(tcpu, vpa);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FLAGS_DEREGISTER_VPA:
|
2018-06-13 08:22:18 +02:00
|
|
|
ret = deregister_vpa(tcpu, vpa);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FLAGS_REGISTER_SLBSHADOW:
|
2018-06-13 08:22:18 +02:00
|
|
|
ret = register_slb_shadow(tcpu, vpa);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FLAGS_DEREGISTER_SLBSHADOW:
|
2018-06-13 08:22:18 +02:00
|
|
|
ret = deregister_slb_shadow(tcpu, vpa);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FLAGS_REGISTER_DTL:
|
2018-06-13 08:22:18 +02:00
|
|
|
ret = register_dtl(tcpu, vpa);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FLAGS_DEREGISTER_DTL:
|
2018-06-13 08:22:18 +02:00
|
|
|
ret = deregister_dtl(tcpu, vpa);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_cede(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
2012-05-03 06:23:01 +02:00
|
|
|
CPUPPCState *env = &cpu->env;
|
2012-12-17 08:02:44 +01:00
|
|
|
CPUState *cs = CPU(cpu);
|
2019-07-18 05:42:12 +02:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
2012-05-03 06:23:01 +02:00
|
|
|
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
env->msr |= (1ULL << MSR_EE);
|
|
|
|
hreg_compute_hflags(env);
|
2019-07-18 05:42:12 +02:00
|
|
|
|
|
|
|
if (spapr_cpu->prod) {
|
|
|
|
spapr_cpu->prod = false;
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-12-17 08:02:44 +01:00
|
|
|
if (!cpu_has_work(cs)) {
|
2013-01-17 18:51:17 +01:00
|
|
|
cs->halted = 1;
|
2013-08-26 08:31:06 +02:00
|
|
|
cs->exception_index = EXCP_HLT;
|
2012-12-17 08:02:44 +01:00
|
|
|
cs->exit_request = 1;
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
}
|
2019-07-18 05:42:12 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-07-18 05:42:14 +02:00
|
|
|
/*
|
|
|
|
* Confer to self, aka join. Cede could use the same pattern as well, if
|
|
|
|
* EXCP_HLT can be changed to ECXP_HALTED.
|
|
|
|
*/
|
|
|
|
static target_ulong h_confer_self(PowerPCCPU *cpu)
|
|
|
|
{
|
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
|
|
|
|
|
|
|
if (spapr_cpu->prod) {
|
|
|
|
spapr_cpu->prod = false;
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
cs->halted = 1;
|
|
|
|
cs->exception_index = EXCP_HALTED;
|
|
|
|
cs->exit_request = 1;
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static target_ulong h_join(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
CPUState *cs;
|
|
|
|
bool last_unjoined = true;
|
|
|
|
|
|
|
|
if (env->msr & (1ULL << MSR_EE)) {
|
|
|
|
return H_BAD_MODE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Must not join the last CPU running. Interestingly, no such restriction
|
|
|
|
* for H_CONFER-to-self, but that is probably not intended to be used
|
|
|
|
* when H_JOIN is available.
|
|
|
|
*/
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
PowerPCCPU *c = POWERPC_CPU(cs);
|
|
|
|
CPUPPCState *e = &c->env;
|
|
|
|
if (c == cpu) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Don't have a way to indicate joined, so use halted && MSR[EE]=0 */
|
|
|
|
if (!cs->halted || (e->msr & (1ULL << MSR_EE))) {
|
|
|
|
last_unjoined = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (last_unjoined) {
|
|
|
|
return H_CONTINUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return h_confer_self(cpu);
|
|
|
|
}
|
|
|
|
|
2019-07-18 05:42:13 +02:00
|
|
|
static target_ulong h_confer(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_long target = args[0];
|
|
|
|
uint32_t dispatch = args[1];
|
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
SpaprCpuState *spapr_cpu;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* -1 means confer to all other CPUs without dispatch counter check,
|
|
|
|
* otherwise it's a targeted confer.
|
|
|
|
*/
|
|
|
|
if (target != -1) {
|
|
|
|
PowerPCCPU *target_cpu = spapr_find_cpu(target);
|
|
|
|
uint32_t target_dispatch;
|
|
|
|
|
|
|
|
if (!target_cpu) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* target == self is a special case, we wait until prodded, without
|
|
|
|
* dispatch counter check.
|
|
|
|
*/
|
|
|
|
if (cpu == target_cpu) {
|
2019-07-18 05:42:14 +02:00
|
|
|
return h_confer_self(cpu);
|
2019-07-18 05:42:13 +02:00
|
|
|
}
|
|
|
|
|
2019-07-18 05:42:14 +02:00
|
|
|
spapr_cpu = spapr_cpu_state(target_cpu);
|
2019-07-18 05:42:13 +02:00
|
|
|
if (!spapr_cpu->vpa_addr || ((dispatch & 1) == 0)) {
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
target_dispatch = ldl_be_phys(cs->as,
|
|
|
|
spapr_cpu->vpa_addr + VPA_DISPATCH_COUNTER);
|
|
|
|
if (target_dispatch != dispatch) {
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The targeted confer does not do anything special beyond yielding
|
|
|
|
* the current vCPU, but even this should be better than nothing.
|
|
|
|
* At least for single-threaded tcg, it gives the target a chance to
|
|
|
|
* run before we run again. Multi-threaded tcg does not really do
|
|
|
|
* anything with EXCP_YIELD yet.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
|
|
|
cs->exception_index = EXCP_YIELD;
|
|
|
|
cs->exit_request = 1;
|
|
|
|
cpu_loop_exit(cs);
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-07-18 05:42:12 +02:00
|
|
|
static target_ulong h_prod(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_long target = args[0];
|
|
|
|
PowerPCCPU *tcpu;
|
|
|
|
CPUState *cs;
|
|
|
|
SpaprCpuState *spapr_cpu;
|
|
|
|
|
|
|
|
tcpu = spapr_find_cpu(target);
|
|
|
|
cs = CPU(tcpu);
|
|
|
|
if (!cs) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
spapr_cpu = spapr_cpu_state(tcpu);
|
|
|
|
spapr_cpu->prod = true;
|
|
|
|
cs->halted = 0;
|
|
|
|
qemu_cpu_kick(cs);
|
|
|
|
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_rtas(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2011-04-01 06:15:23 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong rtas_r3 = args[0];
|
2013-09-27 10:10:18 +02:00
|
|
|
uint32_t token = rtas_ld(rtas_r3, 0);
|
|
|
|
uint32_t nargs = rtas_ld(rtas_r3, 1);
|
|
|
|
uint32_t nret = rtas_ld(rtas_r3, 2);
|
2011-04-01 06:15:23 +02:00
|
|
|
|
2013-06-19 22:40:30 +02:00
|
|
|
return spapr_rtas_call(cpu, spapr, token, nargs, rtas_r3 + 12,
|
2011-04-01 06:15:23 +02:00
|
|
|
nret, rtas_r3 + 12 + 4*nargs);
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_logical_load(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2011-08-10 16:44:20 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
2013-11-15 14:46:38 +01:00
|
|
|
CPUState *cs = CPU(cpu);
|
2011-08-10 16:44:20 +02:00
|
|
|
target_ulong size = args[0];
|
|
|
|
target_ulong addr = args[1];
|
|
|
|
|
|
|
|
switch (size) {
|
|
|
|
case 1:
|
2013-12-17 05:05:40 +01:00
|
|
|
args[0] = ldub_phys(cs->as, addr);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
case 2:
|
2013-12-17 05:33:56 +01:00
|
|
|
args[0] = lduw_phys(cs->as, addr);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
case 4:
|
2013-11-15 14:46:38 +01:00
|
|
|
args[0] = ldl_phys(cs->as, addr);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
case 8:
|
2013-12-17 05:05:40 +01:00
|
|
|
args[0] = ldq_phys(cs->as, addr);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_logical_store(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2011-08-10 16:44:20 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
2013-11-28 00:11:44 +01:00
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
|
2011-08-10 16:44:20 +02:00
|
|
|
target_ulong size = args[0];
|
|
|
|
target_ulong addr = args[1];
|
|
|
|
target_ulong val = args[2];
|
|
|
|
|
|
|
|
switch (size) {
|
|
|
|
case 1:
|
2013-12-17 06:29:06 +01:00
|
|
|
stb_phys(cs->as, addr, val);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
case 2:
|
2013-12-17 06:22:06 +01:00
|
|
|
stw_phys(cs->as, addr, val);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
case 4:
|
2013-12-17 06:07:29 +01:00
|
|
|
stl_phys(cs->as, addr, val);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
case 8:
|
2013-11-28 00:11:44 +01:00
|
|
|
stq_phys(cs->as, addr, val);
|
2011-08-10 16:44:20 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_logical_memop(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2012-06-18 22:21:37 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
2013-11-15 14:46:38 +01:00
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
|
2012-06-18 22:21:37 +02:00
|
|
|
target_ulong dst = args[0]; /* Destination address */
|
|
|
|
target_ulong src = args[1]; /* Source address */
|
|
|
|
target_ulong esize = args[2]; /* Element size (0=1,1=2,2=4,3=8) */
|
|
|
|
target_ulong count = args[3]; /* Element count */
|
|
|
|
target_ulong op = args[4]; /* 0 = copy, 1 = invert */
|
|
|
|
uint64_t tmp;
|
|
|
|
unsigned int mask = (1 << esize) - 1;
|
|
|
|
int step = 1 << esize;
|
|
|
|
|
|
|
|
if (count > 0x80000000) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((dst & mask) || (src & mask) || (op > 1)) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dst >= src && dst < (src + (count << esize))) {
|
|
|
|
dst = dst + ((count - 1) << esize);
|
|
|
|
src = src + ((count - 1) << esize);
|
|
|
|
step = -step;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (count--) {
|
|
|
|
switch (esize) {
|
|
|
|
case 0:
|
2013-12-17 05:05:40 +01:00
|
|
|
tmp = ldub_phys(cs->as, src);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
case 1:
|
2013-12-17 05:33:56 +01:00
|
|
|
tmp = lduw_phys(cs->as, src);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
case 2:
|
2013-11-15 14:46:38 +01:00
|
|
|
tmp = ldl_phys(cs->as, src);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
case 3:
|
2013-12-17 05:05:40 +01:00
|
|
|
tmp = ldq_phys(cs->as, src);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
if (op == 1) {
|
|
|
|
tmp = ~tmp;
|
|
|
|
}
|
|
|
|
switch (esize) {
|
|
|
|
case 0:
|
2013-12-17 06:29:06 +01:00
|
|
|
stb_phys(cs->as, dst, tmp);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
case 1:
|
2013-12-17 06:22:06 +01:00
|
|
|
stw_phys(cs->as, dst, tmp);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
case 2:
|
2013-12-17 06:07:29 +01:00
|
|
|
stl_phys(cs->as, dst, tmp);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
case 3:
|
2013-11-28 00:11:44 +01:00
|
|
|
stq_phys(cs->as, dst, tmp);
|
2012-06-18 22:21:37 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
dst = dst + step;
|
|
|
|
src = src + step;
|
|
|
|
}
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_logical_icbi(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2011-08-10 16:44:20 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
/* Nothing to do on emulation, KVM will trap this in the kernel */
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_logical_dcbf(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2011-08-10 16:44:20 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
/* Nothing to do on emulation, KVM will trap this in the kernel */
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2014-07-08 17:02:26 +02:00
|
|
|
static target_ulong h_set_mode_resource_le(PowerPCCPU *cpu,
|
2020-12-09 18:00:49 +01:00
|
|
|
SpaprMachineState *spapr,
|
2014-07-08 17:02:26 +02:00
|
|
|
target_ulong mflags,
|
|
|
|
target_ulong value1,
|
|
|
|
target_ulong value2)
|
2013-08-19 13:04:20 +02:00
|
|
|
{
|
2014-06-04 14:51:04 +02:00
|
|
|
if (value1) {
|
|
|
|
return H_P3;
|
|
|
|
}
|
|
|
|
if (value2) {
|
|
|
|
return H_P4;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (mflags) {
|
|
|
|
case H_SET_MODE_ENDIAN_BIG:
|
2019-02-15 18:00:18 +01:00
|
|
|
spapr_set_all_lpcrs(0, LPCR_ILE);
|
2020-12-09 18:00:49 +01:00
|
|
|
spapr_pci_switch_vga(spapr, true);
|
2014-06-04 14:51:04 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
|
|
|
|
case H_SET_MODE_ENDIAN_LITTLE:
|
2019-02-15 18:00:18 +01:00
|
|
|
spapr_set_all_lpcrs(LPCR_ILE, LPCR_ILE);
|
2020-12-09 18:00:49 +01:00
|
|
|
spapr_pci_switch_vga(spapr, false);
|
2014-06-04 14:51:04 +02:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
2013-08-19 13:04:20 +02:00
|
|
|
|
2014-06-04 14:51:04 +02:00
|
|
|
return H_UNSUPPORTED_FLAG;
|
|
|
|
}
|
2013-08-19 13:04:20 +02:00
|
|
|
|
2014-07-08 17:02:26 +02:00
|
|
|
static target_ulong h_set_mode_resource_addr_trans_mode(PowerPCCPU *cpu,
|
|
|
|
target_ulong mflags,
|
|
|
|
target_ulong value1,
|
|
|
|
target_ulong value2)
|
2014-06-04 14:51:05 +02:00
|
|
|
{
|
|
|
|
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
|
|
|
|
|
|
|
|
if (!(pcc->insns_flags2 & PPC2_ISA207S)) {
|
|
|
|
return H_P2;
|
|
|
|
}
|
|
|
|
if (value1) {
|
|
|
|
return H_P3;
|
|
|
|
}
|
|
|
|
if (value2) {
|
|
|
|
return H_P4;
|
|
|
|
}
|
|
|
|
|
2021-05-01 09:24:34 +02:00
|
|
|
if (mflags == 1) {
|
2021-05-01 09:24:35 +02:00
|
|
|
/* AIL=1 is reserved in POWER8/POWER9/POWER10 */
|
|
|
|
return H_UNSUPPORTED_FLAG;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mflags == 2 && (pcc->insns_flags2 & PPC2_ISA310)) {
|
|
|
|
/* AIL=2 is reserved in POWER10 (ISA v3.1) */
|
2014-06-04 14:51:05 +02:00
|
|
|
return H_UNSUPPORTED_FLAG;
|
|
|
|
}
|
|
|
|
|
2019-02-15 18:00:18 +01:00
|
|
|
spapr_set_all_lpcrs(mflags << LPCR_AIL_SHIFT, LPCR_AIL);
|
2014-06-04 14:51:05 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_set_mode(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2014-06-04 14:51:04 +02:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong resource = args[1];
|
|
|
|
target_ulong ret = H_P2;
|
|
|
|
|
|
|
|
switch (resource) {
|
|
|
|
case H_SET_MODE_RESOURCE_LE:
|
2020-12-09 18:00:49 +01:00
|
|
|
ret = h_set_mode_resource_le(cpu, spapr, args[0], args[2], args[3]);
|
2014-06-04 14:51:04 +02:00
|
|
|
break;
|
2014-06-04 14:51:05 +02:00
|
|
|
case H_SET_MODE_RESOURCE_ADDR_TRANS_MODE:
|
2014-07-08 17:02:26 +02:00
|
|
|
ret = h_set_mode_resource_addr_trans_mode(cpu, args[0],
|
|
|
|
args[2], args[3]);
|
2014-06-04 14:51:05 +02:00
|
|
|
break;
|
2013-08-19 13:04:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_clean_slb(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2017-03-20 00:46:45 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
qemu_log_mask(LOG_UNIMP, "Unimplemented SPAPR hcall 0x"TARGET_FMT_lx"%s\n",
|
|
|
|
opcode, " (H_CLEAN_SLB)");
|
|
|
|
return H_FUNCTION;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_invalidate_pid(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2017-03-20 00:46:45 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
qemu_log_mask(LOG_UNIMP, "Unimplemented SPAPR hcall 0x"TARGET_FMT_lx"%s\n",
|
|
|
|
opcode, " (H_INVALIDATE_PID)");
|
|
|
|
return H_FUNCTION;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static void spapr_check_setup_free_hpt(SpaprMachineState *spapr,
|
2017-03-20 00:46:46 +01:00
|
|
|
uint64_t patbe_old, uint64_t patbe_new)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We have 4 Options:
|
|
|
|
* HASH->HASH || RADIX->RADIX || NOTHING->RADIX : Do Nothing
|
|
|
|
* HASH->RADIX : Free HPT
|
|
|
|
* RADIX->HASH : Allocate HPT
|
|
|
|
* NOTHING->HASH : Allocate HPT
|
|
|
|
* Note: NOTHING implies the case where we said the guest could choose
|
|
|
|
* later and so assumed radix and now it's called H_REG_PROC_TBL
|
|
|
|
*/
|
|
|
|
|
2019-02-15 18:00:27 +01:00
|
|
|
if ((patbe_old & PATE1_GR) == (patbe_new & PATE1_GR)) {
|
2017-03-20 00:46:46 +01:00
|
|
|
/* We assume RADIX, so this catches all the "Do Nothing" cases */
|
2019-02-15 18:00:27 +01:00
|
|
|
} else if (!(patbe_old & PATE1_GR)) {
|
2017-03-20 00:46:46 +01:00
|
|
|
/* HASH->RADIX : Free HPT */
|
2017-05-17 05:49:20 +02:00
|
|
|
spapr_free_hpt(spapr);
|
2019-02-15 18:00:27 +01:00
|
|
|
} else if (!(patbe_new & PATE1_GR)) {
|
2017-03-20 00:46:46 +01:00
|
|
|
/* RADIX->HASH || NOTHING->HASH : Allocate HPT */
|
spapr: Don't attempt to clamp RMA to VRMA constraint
The Real Mode Area (RMA) is the part of memory which a guest can access
when in real (MMU off) mode. Of course, for a guest under KVM, the MMU
isn't really turned off, it's just in a special translation mode - Virtual
Real Mode Area (VRMA) - which looks like real mode in guest mode.
The mechanics of how this works when using the hash MMU (HPT) put a
constraint on the size of the RMA, which depends on the size of the
HPT. So, the latter part of spapr_setup_hpt_and_vrma() clamps the RMA
we advertise to the guest based on this VRMA limit.
There are several things wrong with this:
1) spapr_setup_hpt_and_vrma() doesn't actually clamp, it takes the minimum
of Node 0 memory size and the VRMA limit. That will *often* work the
same as clamping, but there can be other constraints on RMA size which
supersede Node 0 memory size. We have real bugs caused by this
(currently worked around in the guest kernel)
2) Some callers of spapr_setup_hpt_and_vrma() are in a situation where
we're past the point that we can actually advertise an RMA limit to the
guest
3) But most fundamentally, the VRMA limit depends on host configuration
(page size) which shouldn't be visible to the guest, but this partially
exposes it. This can cause problems with migration in certain edge
cases, although we will mostly get away with it.
In practice, this clamping is almost never applied anyway. With 64kiB
pages and the normal rules for sizing of the HPT, the theoretical VRMA
limit will be 4x(guest memory size) and so never hit. It will hit with
4kiB pages, where it will be (guest memory size)/4. However all mainstream
distro kernels for POWER have used a 64kiB page size for at least 10 years.
So, simply replace this logic with a check that the RMA we've calculated
based only on guest visible configuration will fit within the host implied
VRMA limit. This can break if running HPT guests on a host kernel with
4kiB page size. As noted that's very rare. There also exist several
possible workarounds:
* Change the host kernel to use 64kiB pages
* Use radix MMU (RPT) guests instead of HPT
* Use 64kiB hugepages on the host to back guest memory
* Increase the guest memory size so that the RMA hits one of the fixed
limits before the RMA limit. This is relatively easy on POWER8 which
has a 16GiB limit, harder on POWER9 which has a 1TiB limit.
* Use a guest NUMA configuration which artificially constrains the RMA
within the VRMA limit (the RMA must always fit within Node 0).
Previously, on KVM, we also temporarily reduced the rma_size to 256M so
that the we'd load the kernel and initrd safely, regardless of the VRMA
limit. This was a) confusing, b) could significantly limit the size of
images we could load and c) introduced a behavioural difference between
KVM and TCG. So we remove that as well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Greg Kurz <groug@kaod.org>
2019-11-28 06:37:04 +01:00
|
|
|
spapr_setup_hpt(spapr);
|
2017-03-20 00:46:46 +01:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define FLAGS_MASK 0x01FULL
|
|
|
|
#define FLAG_MODIFY 0x10
|
|
|
|
#define FLAG_REGISTER 0x08
|
|
|
|
#define FLAG_RADIX 0x04
|
|
|
|
#define FLAG_HASH_PROC_TBL 0x02
|
|
|
|
#define FLAG_GTSE 0x01
|
|
|
|
|
2017-03-20 00:46:45 +01:00
|
|
|
static target_ulong h_register_process_table(PowerPCCPU *cpu,
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineState *spapr,
|
2017-03-20 00:46:45 +01:00
|
|
|
target_ulong opcode,
|
|
|
|
target_ulong *args)
|
|
|
|
{
|
2017-03-20 00:46:46 +01:00
|
|
|
target_ulong flags = args[0];
|
|
|
|
target_ulong proc_tbl = args[1];
|
|
|
|
target_ulong page_size = args[2];
|
|
|
|
target_ulong table_size = args[3];
|
2019-03-05 03:21:02 +01:00
|
|
|
target_ulong update_lpcr = 0;
|
2017-03-20 00:46:46 +01:00
|
|
|
uint64_t cproc;
|
|
|
|
|
|
|
|
if (flags & ~FLAGS_MASK) { /* Check no reserved bits are set */
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
if (flags & FLAG_MODIFY) {
|
|
|
|
if (flags & FLAG_REGISTER) {
|
|
|
|
if (flags & FLAG_RADIX) { /* Register new RADIX process table */
|
|
|
|
if (proc_tbl & 0xfff || proc_tbl >> 60) {
|
|
|
|
return H_P2;
|
|
|
|
} else if (page_size) {
|
|
|
|
return H_P3;
|
|
|
|
} else if (table_size > 24) {
|
|
|
|
return H_P4;
|
|
|
|
}
|
2019-02-15 18:00:27 +01:00
|
|
|
cproc = PATE1_GR | proc_tbl | table_size;
|
2017-03-20 00:46:46 +01:00
|
|
|
} else { /* Register new HPT process table */
|
|
|
|
if (flags & FLAG_HASH_PROC_TBL) { /* Hash with Segment Tables */
|
|
|
|
/* TODO - Not Supported */
|
|
|
|
/* Technically caused by flag bits => H_PARAMETER */
|
|
|
|
return H_PARAMETER;
|
|
|
|
} else { /* Hash with SLB */
|
|
|
|
if (proc_tbl >> 38) {
|
|
|
|
return H_P2;
|
|
|
|
} else if (page_size & ~0x7) {
|
|
|
|
return H_P3;
|
|
|
|
} else if (table_size > 24) {
|
|
|
|
return H_P4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
cproc = (proc_tbl << 25) | page_size << 5 | table_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
} else { /* Deregister current process table */
|
2019-02-15 18:00:27 +01:00
|
|
|
/*
|
|
|
|
* Set to benign value: (current GR) | 0. This allows
|
|
|
|
* deregistration in KVM to succeed even if the radix bit
|
|
|
|
* in flags doesn't match the radix bit in the old PATE.
|
|
|
|
*/
|
|
|
|
cproc = spapr->patb_entry & PATE1_GR;
|
2017-03-20 00:46:46 +01:00
|
|
|
}
|
|
|
|
} else { /* Maintain current registration */
|
2019-02-15 18:00:27 +01:00
|
|
|
if (!(flags & FLAG_RADIX) != !(spapr->patb_entry & PATE1_GR)) {
|
2017-03-20 00:46:46 +01:00
|
|
|
/* Technically caused by flag bits => H_PARAMETER */
|
|
|
|
return H_PARAMETER; /* Existing Process Table Mismatch */
|
|
|
|
}
|
|
|
|
cproc = spapr->patb_entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if we need to setup OR free the hpt */
|
|
|
|
spapr_check_setup_free_hpt(spapr, spapr->patb_entry, cproc);
|
|
|
|
|
|
|
|
spapr->patb_entry = cproc; /* Save new process table */
|
2017-05-02 08:37:14 +02:00
|
|
|
|
2019-02-15 18:00:18 +01:00
|
|
|
/* Update the UPRT, HR and GTSE bits in the LPCR for all cpus */
|
2019-03-05 03:21:02 +01:00
|
|
|
if (flags & FLAG_RADIX) /* Radix must use process tables, also set HR */
|
|
|
|
update_lpcr |= (LPCR_UPRT | LPCR_HR);
|
|
|
|
else if (flags & FLAG_HASH_PROC_TBL) /* Hash with process tables */
|
|
|
|
update_lpcr |= LPCR_UPRT;
|
|
|
|
if (flags & FLAG_GTSE) /* Guest translation shootdown enable */
|
2019-03-13 04:17:27 +01:00
|
|
|
update_lpcr |= LPCR_GTSE;
|
|
|
|
|
2019-03-05 03:21:02 +01:00
|
|
|
spapr_set_all_lpcrs(update_lpcr, LPCR_UPRT | LPCR_HR | LPCR_GTSE);
|
2017-03-20 00:46:46 +01:00
|
|
|
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
return kvmppc_configure_v3_mmu(cpu, flags & FLAG_RADIX,
|
|
|
|
flags & FLAG_GTSE, cproc);
|
|
|
|
}
|
|
|
|
return H_SUCCESS;
|
2017-03-20 00:46:45 +01:00
|
|
|
}
|
|
|
|
|
2016-12-05 06:50:21 +01:00
|
|
|
#define H_SIGNAL_SYS_RESET_ALL -1
|
|
|
|
#define H_SIGNAL_SYS_RESET_ALLBUTSELF -2
|
|
|
|
|
|
|
|
static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineState *spapr,
|
2016-12-05 06:50:21 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_long target = args[0];
|
|
|
|
CPUState *cs;
|
|
|
|
|
|
|
|
if (target < 0) {
|
|
|
|
/* Broadcast */
|
|
|
|
if (target < H_SIGNAL_SYS_RESET_ALLBUTSELF) {
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
PowerPCCPU *c = POWERPC_CPU(cs);
|
|
|
|
|
|
|
|
if (target == H_SIGNAL_SYS_RESET_ALLBUTSELF) {
|
|
|
|
if (c == cpu) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
run_on_cpu(cs, spapr_do_system_reset_on_cpu, RUN_ON_CPU_NULL);
|
|
|
|
}
|
|
|
|
return H_SUCCESS;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/* Unicast */
|
2017-08-09 07:38:56 +02:00
|
|
|
cs = CPU(spapr_find_cpu(target));
|
2017-08-03 08:28:27 +02:00
|
|
|
if (cs) {
|
|
|
|
run_on_cpu(cs, spapr_do_system_reset_on_cpu, RUN_ON_CPU_NULL);
|
|
|
|
return H_SUCCESS;
|
2016-12-05 06:50:21 +01:00
|
|
|
}
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-14 14:34:55 +02:00
|
|
|
/* Returns either a logical PVR or zero if none was found */
|
|
|
|
static uint32_t cas_check_pvr(PowerPCCPU *cpu, uint32_t max_compat,
|
|
|
|
target_ulong *addr, bool *raw_mode_supported)
|
2014-05-23 04:26:54 +02:00
|
|
|
{
|
2016-11-16 03:54:48 +01:00
|
|
|
bool explicit_match = false; /* Matched the CPU's real PVR */
|
|
|
|
uint32_t best_compat = 0;
|
|
|
|
int i;
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
|
2016-11-16 03:54:48 +01:00
|
|
|
/*
|
|
|
|
* We scan the supplied table of PVRs looking for two things
|
|
|
|
* 1. Is our real CPU PVR in the list?
|
|
|
|
* 2. What's the "best" listed logical PVR
|
|
|
|
*/
|
|
|
|
for (i = 0; i < 512; ++i) {
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
uint32_t pvr, pvr_mask;
|
|
|
|
|
2017-05-18 06:47:44 +02:00
|
|
|
pvr_mask = ldl_be_phys(&address_space_memory, *addr);
|
|
|
|
pvr = ldl_be_phys(&address_space_memory, *addr + 4);
|
|
|
|
*addr += 8;
|
2016-11-16 03:54:48 +01:00
|
|
|
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
if (~pvr_mask & pvr) {
|
2016-11-16 03:54:48 +01:00
|
|
|
break; /* Terminator record */
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
}
|
2016-11-16 03:54:48 +01:00
|
|
|
|
|
|
|
if ((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask)) {
|
|
|
|
explicit_match = true;
|
|
|
|
} else {
|
|
|
|
if (ppc_check_compat(cpu, pvr, best_compat, max_compat)) {
|
|
|
|
best_compat = pvr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-17 13:23:50 +02:00
|
|
|
*raw_mode_supported = explicit_match;
|
|
|
|
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
/* Parsing finished */
|
2016-11-16 03:54:48 +01:00
|
|
|
trace_spapr_cas_pvr(cpu->compat_pvr, explicit_match, best_compat);
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
|
2017-05-18 06:47:44 +02:00
|
|
|
return best_compat;
|
|
|
|
}
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
|
2021-01-14 19:06:23 +01:00
|
|
|
static
|
2020-03-25 16:25:42 +01:00
|
|
|
target_ulong do_client_architecture_support(PowerPCCPU *cpu,
|
|
|
|
SpaprMachineState *spapr,
|
|
|
|
target_ulong vec,
|
|
|
|
target_ulong fdt_bufsize)
|
2017-05-18 06:47:44 +02:00
|
|
|
{
|
2020-03-25 16:25:42 +01:00
|
|
|
target_ulong ov_table; /* Working address in data buffer */
|
2017-05-18 06:47:44 +02:00
|
|
|
uint32_t cas_pvr;
|
2020-03-25 16:25:30 +01:00
|
|
|
SpaprOptionVector *ov1_guest, *ov5_guest;
|
2017-05-18 06:47:44 +02:00
|
|
|
bool guest_radix;
|
2017-08-17 13:23:50 +02:00
|
|
|
bool raw_mode_supported = false;
|
2021-07-08 08:56:25 +02:00
|
|
|
bool guest_xive;
|
2020-01-22 14:11:12 +01:00
|
|
|
CPUState *cs;
|
2020-03-25 16:25:49 +01:00
|
|
|
void *fdt;
|
2020-09-14 14:34:55 +02:00
|
|
|
uint32_t max_compat = spapr->max_compat_pvr;
|
2020-01-22 14:11:12 +01:00
|
|
|
|
|
|
|
/* CAS is supposed to be called early when only the boot vCPU is active. */
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
if (cs == CPU(cpu)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!cs->halted) {
|
|
|
|
warn_report("guest has multiple active vCPUs at CAS, which is not allowed");
|
|
|
|
return H_MULTI_THREADS_ACTIVE;
|
|
|
|
}
|
|
|
|
}
|
2017-05-18 06:47:44 +02:00
|
|
|
|
2020-09-14 14:34:55 +02:00
|
|
|
cas_pvr = cas_check_pvr(cpu, max_compat, &vec, &raw_mode_supported);
|
|
|
|
if (!cas_pvr && (!raw_mode_supported || max_compat)) {
|
|
|
|
/*
|
|
|
|
* We couldn't find a suitable compatibility mode, and either
|
|
|
|
* the guest doesn't support "raw" mode for this CPU, or "raw"
|
|
|
|
* mode is disabled because a maximum compat mode is set.
|
|
|
|
*/
|
|
|
|
error_report("Couldn't negotiate a suitable PVR during CAS");
|
2017-05-18 06:47:44 +02:00
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Update CPUs */
|
|
|
|
if (cpu->compat_pvr != cas_pvr) {
|
2020-09-14 14:34:56 +02:00
|
|
|
Error *local_err = NULL;
|
|
|
|
|
|
|
|
if (ppc_set_compat_all(cas_pvr, &local_err) < 0) {
|
2017-08-17 13:23:50 +02:00
|
|
|
/* We fail to set compat mode (likely because running with KVM PR),
|
|
|
|
* but maybe we can fallback to raw mode if the guest supports it.
|
|
|
|
*/
|
|
|
|
if (!raw_mode_supported) {
|
|
|
|
error_report_err(local_err);
|
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
2018-06-12 19:01:26 +02:00
|
|
|
error_free(local_err);
|
spapr: Implement processor compatibility in ibm, client-architecture-support
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>
2014-05-23 04:26:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-13 02:34:00 +02:00
|
|
|
/* For the future use: here @ov_table points to the first option vector */
|
2020-03-25 16:25:42 +01:00
|
|
|
ov_table = vec;
|
2015-07-13 02:34:00 +02:00
|
|
|
|
2017-03-20 00:46:49 +01:00
|
|
|
ov1_guest = spapr_ovec_parse_vector(ov_table, 1);
|
2020-01-17 10:15:52 +01:00
|
|
|
if (!ov1_guest) {
|
|
|
|
warn_report("guest didn't provide option vector 1");
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
2016-10-25 06:47:28 +02:00
|
|
|
ov5_guest = spapr_ovec_parse_vector(ov_table, 5);
|
2020-01-17 10:15:52 +01:00
|
|
|
if (!ov5_guest) {
|
2020-03-21 18:34:22 +01:00
|
|
|
spapr_ovec_cleanup(ov1_guest);
|
2020-01-17 10:15:52 +01:00
|
|
|
warn_report("guest didn't provide option vector 5");
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
2017-03-23 04:46:00 +01:00
|
|
|
if (spapr_ovec_test(ov5_guest, OV5_MMU_BOTH)) {
|
|
|
|
error_report("guest requested hash and radix MMU, which is invalid.");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
2019-05-15 19:04:24 +02:00
|
|
|
if (spapr_ovec_test(ov5_guest, OV5_XIVE_BOTH)) {
|
|
|
|
error_report("guest requested an invalid interrupt mode");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
2017-03-23 04:46:00 +01:00
|
|
|
guest_radix = spapr_ovec_test(ov5_guest, OV5_MMU_RADIX_300);
|
2014-05-23 04:26:54 +02:00
|
|
|
|
2019-05-15 19:04:24 +02:00
|
|
|
guest_xive = spapr_ovec_test(ov5_guest, OV5_XIVE_EXPLOIT);
|
|
|
|
|
2017-07-12 09:56:06 +02:00
|
|
|
/*
|
|
|
|
* HPT resizing is a bit of a special case, because when enabled
|
|
|
|
* we assume an HPT guest will support it until it says it
|
|
|
|
* doesn't, instead of assuming it won't support it until it says
|
|
|
|
* it does. Strictly speaking that approach could break for
|
|
|
|
* guests which don't make a CAS call, but those are so old we
|
|
|
|
* don't care about them. Without that assumption we'd have to
|
|
|
|
* make at least a temporary allocation of an HPT sized for max
|
|
|
|
* memory, which could be impossibly difficult under KVM HV if
|
|
|
|
* maxram is large.
|
|
|
|
*/
|
|
|
|
if (!guest_radix && !spapr_ovec_test(ov5_guest, OV5_HPT_RESIZE)) {
|
|
|
|
int maxshift = spapr_hpt_shift_for_ramsize(MACHINE(spapr)->maxram_size);
|
|
|
|
|
|
|
|
if (spapr->resize_hpt == SPAPR_RESIZE_HPT_REQUIRED) {
|
|
|
|
error_report(
|
|
|
|
"h_client_architecture_support: Guest doesn't support HPT resizing, but resize-hpt=required");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (spapr->htab_shift < maxshift) {
|
|
|
|
/* Guest doesn't know about HPT resizing, so we
|
|
|
|
* pre-emptively resize for the maximum permitted RAM. At
|
|
|
|
* the point this is called, nothing should have been
|
|
|
|
* entered into the existing HPT */
|
|
|
|
spapr_reallocate_hpt(spapr, maxshift, &error_fatal);
|
2017-09-25 13:00:02 +02:00
|
|
|
push_sregs_to_kvm_pr(spapr);
|
2017-07-12 09:56:06 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-25 06:47:28 +02:00
|
|
|
/* NOTE: there are actually a number of ov5 bits where input from the
|
|
|
|
* guest is always zero, and the platform/QEMU enables them independently
|
|
|
|
* of guest input. To model these properly we'd want some sort of mask,
|
|
|
|
* but since they only currently apply to memory migration as defined
|
|
|
|
* by LoPAPR 1.1, 14.5.4.8, which QEMU doesn't implement, we don't need
|
spapr: add option vector handling in CAS-generated resets
In some cases, ibm,client-architecture-support calls can fail. This
could happen in the current code for situations where the modified
device tree segment exceeds the buffer size provided by the guest
via the call parameters. In these cases, QEMU will reset, allowing
an opportunity to regenerate the device tree from scratch via
boot-time handling. There are potentially other scenarios as well,
not currently reachable in the current code, but possible in theory,
such as cases where device-tree properties or nodes need to be removed.
We currently don't handle either of these properly for option vector
capabilities however. Instead of carrying the negotiated capability
beyond the reset and creating the boot-time device tree accordingly,
we start from scratch, generating the same boot-time device tree as we
did prior to the CAS-generated and the same device tree updates as we
did before. This could (in theory) cause us to get stuck in a reset
loop. This hasn't been observed, but depending on the extensiveness
of CAS-induced device tree updates in the future, could eventually
become an issue.
Address this by pulling capability-related device tree
updates resulting from CAS calls into a common routine,
spapr_dt_cas_updates(), and adding an sPAPROptionVector*
parameter that allows us to test for newly-negotiated capabilities.
We invoke it as follows:
1) When ibm,client-architecture-support gets called, we
call spapr_dt_cas_updates() with the set of capabilities
added since the previous call to ibm,client-architecture-support.
For the initial boot, or a system reset generated by something
other than the CAS call itself, this set will consist of *all*
options supported both the platform and the guest. For calls
to ibm,client-architecture-support immediately after a CAS-induced
reset, we call spapr_dt_cas_updates() with only the set
of capabilities added since the previous call, since the other
capabilities will have already been addressed by the boot-time
device-tree this time around. In the unlikely event that
capabilities are *removed* since the previous CAS, we will
generate a CAS-induced reset. In the unlikely event that we
cannot fit the device-tree updates into the buffer provided
by the guest, well generate a CAS-induced reset.
2) When a CAS update results in the need to reset the machine and
include the updates in the boot-time device tree, we call the
spapr_dt_cas_updates() using the full set of negotiated
capabilities as part of the reset path. At initial boot, or after
a reset generated by something other than the CAS call itself,
this set will be empty, resulting in what should be the same
boot-time device-tree as we generated prior to this patch. For
CAS-induced reset, this routine will be called with the full set of
capabilities negotiated by the platform/guest in the previous
CAS call, which should result in CAS updates from previous call
being accounted for in the initial boot-time device tree.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[dwg: Changed an int -> bool conversion to be more explicit]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-25 06:47:29 +02:00
|
|
|
* to worry about this for now.
|
2016-10-25 06:47:28 +02:00
|
|
|
*/
|
2017-09-08 16:33:43 +02:00
|
|
|
|
spapr: add option vector handling in CAS-generated resets
In some cases, ibm,client-architecture-support calls can fail. This
could happen in the current code for situations where the modified
device tree segment exceeds the buffer size provided by the guest
via the call parameters. In these cases, QEMU will reset, allowing
an opportunity to regenerate the device tree from scratch via
boot-time handling. There are potentially other scenarios as well,
not currently reachable in the current code, but possible in theory,
such as cases where device-tree properties or nodes need to be removed.
We currently don't handle either of these properly for option vector
capabilities however. Instead of carrying the negotiated capability
beyond the reset and creating the boot-time device tree accordingly,
we start from scratch, generating the same boot-time device tree as we
did prior to the CAS-generated and the same device tree updates as we
did before. This could (in theory) cause us to get stuck in a reset
loop. This hasn't been observed, but depending on the extensiveness
of CAS-induced device tree updates in the future, could eventually
become an issue.
Address this by pulling capability-related device tree
updates resulting from CAS calls into a common routine,
spapr_dt_cas_updates(), and adding an sPAPROptionVector*
parameter that allows us to test for newly-negotiated capabilities.
We invoke it as follows:
1) When ibm,client-architecture-support gets called, we
call spapr_dt_cas_updates() with the set of capabilities
added since the previous call to ibm,client-architecture-support.
For the initial boot, or a system reset generated by something
other than the CAS call itself, this set will consist of *all*
options supported both the platform and the guest. For calls
to ibm,client-architecture-support immediately after a CAS-induced
reset, we call spapr_dt_cas_updates() with only the set
of capabilities added since the previous call, since the other
capabilities will have already been addressed by the boot-time
device-tree this time around. In the unlikely event that
capabilities are *removed* since the previous CAS, we will
generate a CAS-induced reset. In the unlikely event that we
cannot fit the device-tree updates into the buffer provided
by the guest, well generate a CAS-induced reset.
2) When a CAS update results in the need to reset the machine and
include the updates in the boot-time device tree, we call the
spapr_dt_cas_updates() using the full set of negotiated
capabilities as part of the reset path. At initial boot, or after
a reset generated by something other than the CAS call itself,
this set will be empty, resulting in what should be the same
boot-time device-tree as we generated prior to this patch. For
CAS-induced reset, this routine will be called with the full set of
capabilities negotiated by the platform/guest in the previous
CAS call, which should result in CAS updates from previous call
being accounted for in the initial boot-time device tree.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[dwg: Changed an int -> bool conversion to be more explicit]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-25 06:47:29 +02:00
|
|
|
/* full range of negotiated ov5 capabilities */
|
2016-10-25 06:47:28 +02:00
|
|
|
spapr_ovec_intersect(spapr->ov5_cas, spapr->ov5, ov5_guest);
|
|
|
|
spapr_ovec_cleanup(ov5_guest);
|
2020-03-25 16:25:36 +01:00
|
|
|
|
2021-05-05 02:11:29 +02:00
|
|
|
spapr_check_mmu_mode(guest_radix);
|
|
|
|
|
2019-08-28 05:59:27 +02:00
|
|
|
spapr->cas_pre_isa3_guest = !spapr_ovec_test(ov1_guest, OV1_PPC_3_00);
|
2019-07-17 10:20:31 +02:00
|
|
|
spapr_ovec_cleanup(ov1_guest);
|
2019-01-02 06:57:42 +01:00
|
|
|
|
2019-05-15 19:04:24 +02:00
|
|
|
/*
|
2019-10-18 06:19:31 +02:00
|
|
|
* Ensure the guest asks for an interrupt mode we support;
|
|
|
|
* otherwise terminate the boot.
|
2019-05-15 19:04:24 +02:00
|
|
|
*/
|
|
|
|
if (guest_xive) {
|
2019-09-25 07:12:07 +02:00
|
|
|
if (!spapr->irq->xive) {
|
2019-05-16 09:36:57 +02:00
|
|
|
error_report(
|
|
|
|
"Guest requested unavailable interrupt mode (XIVE), try the ic-mode=xive or ic-mode=dual machine property");
|
2019-05-15 19:04:24 +02:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
} else {
|
2019-09-25 07:12:07 +02:00
|
|
|
if (!spapr->irq->xics) {
|
2019-05-16 09:36:57 +02:00
|
|
|
error_report(
|
|
|
|
"Guest requested unavailable interrupt mode (XICS), either don't set the ic-mode machine property or try ic-mode=xics or ic-mode=dual");
|
2019-05-15 19:04:24 +02:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-18 06:19:31 +02:00
|
|
|
spapr_irq_update_active_intc(spapr);
|
|
|
|
|
2020-12-18 11:33:57 +01:00
|
|
|
/*
|
|
|
|
* Process all pending hot-plug/unplug requests now. An updated full
|
|
|
|
* rendered FDT will be returned to the guest.
|
|
|
|
*/
|
|
|
|
spapr_drc_reset_all(spapr);
|
|
|
|
spapr_clear_pending_hotplug_events(spapr);
|
2019-11-29 05:00:58 +01:00
|
|
|
|
2020-03-25 16:25:49 +01:00
|
|
|
/*
|
|
|
|
* If spapr_machine_reset() did not set up a HPT but one is necessary
|
|
|
|
* (because the guest isn't going to use radix) then set it up here.
|
|
|
|
*/
|
|
|
|
if ((spapr->patb_entry & PATE1_GR) && !guest_radix) {
|
|
|
|
/* legacy hash or new hash: */
|
|
|
|
spapr_setup_hpt(spapr);
|
2019-01-02 06:57:42 +01:00
|
|
|
}
|
|
|
|
|
2021-07-08 08:56:25 +02:00
|
|
|
fdt = spapr_build_fdt(spapr, spapr->vof != NULL, fdt_bufsize);
|
2020-03-25 16:25:49 +01:00
|
|
|
g_free(spapr->fdt_blob);
|
|
|
|
spapr->fdt_size = fdt_totalsize(fdt);
|
|
|
|
spapr->fdt_initial_size = spapr->fdt_size;
|
|
|
|
spapr->fdt_blob = fdt;
|
2014-05-23 04:26:54 +02:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2020-03-25 16:25:42 +01:00
|
|
|
static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
|
|
|
|
SpaprMachineState *spapr,
|
|
|
|
target_ulong opcode,
|
|
|
|
target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong vec = ppc64_phys_to_real(args[0]);
|
|
|
|
target_ulong fdt_buf = args[1];
|
|
|
|
target_ulong fdt_bufsize = args[2];
|
|
|
|
target_ulong ret;
|
|
|
|
SpaprDeviceTreeUpdateHeader hdr = { .version_id = 1 };
|
|
|
|
|
|
|
|
if (fdt_bufsize < sizeof(hdr)) {
|
|
|
|
error_report("SLOF provided insufficient CAS buffer "
|
|
|
|
TARGET_FMT_lu " (min: %zu)", fdt_bufsize, sizeof(hdr));
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
fdt_bufsize -= sizeof(hdr);
|
|
|
|
|
|
|
|
ret = do_client_architecture_support(cpu, spapr, vec, fdt_bufsize);
|
|
|
|
if (ret == H_SUCCESS) {
|
|
|
|
_FDT((fdt_pack(spapr->fdt_blob)));
|
|
|
|
spapr->fdt_size = fdt_totalsize(spapr->fdt_blob);
|
|
|
|
spapr->fdt_initial_size = spapr->fdt_size;
|
|
|
|
|
|
|
|
cpu_physical_memory_write(fdt_buf, &hdr, sizeof(hdr));
|
|
|
|
cpu_physical_memory_write(fdt_buf + sizeof(hdr), spapr->fdt_blob,
|
|
|
|
spapr->fdt_size);
|
|
|
|
trace_spapr_cas_continue(spapr->fdt_size + sizeof(hdr));
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
spapr: Implement Open Firmware client interface
The PAPR platform describes an OS environment that's presented by
a combination of a hypervisor and firmware. The features it specifies
require collaboration between the firmware and the hypervisor.
Since the beginning, the runtime component of the firmware (RTAS) has
been implemented as a 20 byte shim which simply forwards it to
a hypercall implemented in qemu. The boot time firmware component is
SLOF - but a build that's specific to qemu, and has always needed to be
updated in sync with it. Even though we've managed to limit the amount
of runtime communication we need between qemu and SLOF, there's some,
and it has become increasingly awkward to handle as we've implemented
new features.
This implements a boot time OF client interface (CI) which is
enabled by a new "x-vof" pseries machine option (stands for "Virtual Open
Firmware). When enabled, QEMU implements the custom H_OF_CLIENT hcall
which implements Open Firmware Client Interface (OF CI). This allows
using a smaller stateless firmware which does not have to manage
the device tree.
The new "vof.bin" firmware image is included with source code under
pc-bios/. It also includes RTAS blob.
This implements a handful of CI methods just to get -kernel/-initrd
working. In particular, this implements the device tree fetching and
simple memory allocator - "claim" (an OF CI memory allocator) and updates
"/memory@0/available" to report the client about available memory.
This implements changing some device tree properties which we know how
to deal with, the rest is ignored. To allow changes, this skips
fdt_pack() when x-vof=on as not packing the blob leaves some room for
appending.
In absence of SLOF, this assigns phandles to device tree nodes to make
device tree traversing work.
When x-vof=on, this adds "/chosen" every time QEMU (re)builds a tree.
This adds basic instances support which are managed by a hash map
ihandle -> [phandle].
Before the guest started, the used memory is:
0..e60 - the initial firmware
8000..10000 - stack
400000.. - kernel
3ea0000.. - initramdisk
This OF CI does not implement "interpret".
Unlike SLOF, this does not format uninitialized nvram. Instead, this
includes a disk image with pre-formatted nvram.
With this basic support, this can only boot into kernel directly.
However this is just enough for the petitboot kernel and initradmdisk to
boot from any possible source. Note this requires reasonably recent guest
kernel with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5be5be8735
The immediate benefit is much faster booting time which especially
crucial with fully emulated early CPU bring up environments. Also this
may come handy when/if GRUB-in-the-userspace sees light of the day.
This separates VOF and sPAPR in a hope that VOF bits may be reused by
other POWERPC boards which do not support pSeries.
This assumes potential support for booting from QEMU backends
such as blockdev or netdev without devices/drivers used.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Message-Id: <20210625055155.2252896-1-aik@ozlabs.ru>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
[dwg: Adjusted some includes which broke compile in some more obscure
compilation setups]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-06-25 07:51:55 +02:00
|
|
|
target_ulong spapr_vof_client_architecture_support(MachineState *ms,
|
|
|
|
CPUState *cs,
|
|
|
|
target_ulong ovec_addr)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(ms);
|
|
|
|
|
|
|
|
target_ulong ret = do_client_architecture_support(POWERPC_CPU(cs), spapr,
|
|
|
|
ovec_addr, FDT_MAX_SIZE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This adds stdout and generates phandles for boottime and CAS FDTs.
|
|
|
|
* It is alright to update the FDT here as do_client_architecture_support()
|
|
|
|
* does not pack it.
|
|
|
|
*/
|
|
|
|
spapr_vof_client_dt_finalize(spapr, spapr->fdt_blob);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-01-19 06:00:05 +01:00
|
|
|
static target_ulong h_get_cpu_characteristics(PowerPCCPU *cpu,
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineState *spapr,
|
2018-01-19 06:00:05 +01:00
|
|
|
target_ulong opcode,
|
|
|
|
target_ulong *args)
|
|
|
|
{
|
|
|
|
uint64_t characteristics = H_CPU_CHAR_HON_BRANCH_HINTS &
|
|
|
|
~H_CPU_CHAR_THR_RECONF_TRIG;
|
|
|
|
uint64_t behaviour = H_CPU_BEHAV_FAVOUR_SECURITY;
|
|
|
|
uint8_t safe_cache = spapr_get_cap(spapr, SPAPR_CAP_CFPC);
|
|
|
|
uint8_t safe_bounds_check = spapr_get_cap(spapr, SPAPR_CAP_SBBC);
|
|
|
|
uint8_t safe_indirect_branch = spapr_get_cap(spapr, SPAPR_CAP_IBS);
|
2019-03-01 04:19:12 +01:00
|
|
|
uint8_t count_cache_flush_assist = spapr_get_cap(spapr,
|
|
|
|
SPAPR_CAP_CCF_ASSIST);
|
2018-01-19 06:00:05 +01:00
|
|
|
|
|
|
|
switch (safe_cache) {
|
|
|
|
case SPAPR_CAP_WORKAROUND:
|
|
|
|
characteristics |= H_CPU_CHAR_L1D_FLUSH_ORI30;
|
|
|
|
characteristics |= H_CPU_CHAR_L1D_FLUSH_TRIG2;
|
|
|
|
characteristics |= H_CPU_CHAR_L1D_THREAD_PRIV;
|
|
|
|
behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
|
|
|
|
break;
|
|
|
|
case SPAPR_CAP_FIXED:
|
2021-06-15 06:41:07 +02:00
|
|
|
behaviour |= H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY;
|
|
|
|
behaviour |= H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS;
|
2018-01-19 06:00:05 +01:00
|
|
|
break;
|
|
|
|
default: /* broken */
|
|
|
|
assert(safe_cache == SPAPR_CAP_BROKEN);
|
|
|
|
behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (safe_bounds_check) {
|
|
|
|
case SPAPR_CAP_WORKAROUND:
|
|
|
|
characteristics |= H_CPU_CHAR_SPEC_BAR_ORI31;
|
|
|
|
behaviour |= H_CPU_BEHAV_BNDS_CHK_SPEC_BAR;
|
|
|
|
break;
|
|
|
|
case SPAPR_CAP_FIXED:
|
|
|
|
break;
|
|
|
|
default: /* broken */
|
|
|
|
assert(safe_bounds_check == SPAPR_CAP_BROKEN);
|
|
|
|
behaviour |= H_CPU_BEHAV_BNDS_CHK_SPEC_BAR;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (safe_indirect_branch) {
|
2019-03-01 04:19:11 +01:00
|
|
|
case SPAPR_CAP_FIXED_NA:
|
|
|
|
break;
|
2018-03-01 07:38:02 +01:00
|
|
|
case SPAPR_CAP_FIXED_CCD:
|
|
|
|
characteristics |= H_CPU_CHAR_CACHE_COUNT_DIS;
|
|
|
|
break;
|
|
|
|
case SPAPR_CAP_FIXED_IBS:
|
2018-01-19 06:00:05 +01:00
|
|
|
characteristics |= H_CPU_CHAR_BCCTRL_SERIALISED;
|
2018-02-01 20:47:41 +01:00
|
|
|
break;
|
2019-03-01 04:19:11 +01:00
|
|
|
case SPAPR_CAP_WORKAROUND:
|
|
|
|
behaviour |= H_CPU_BEHAV_FLUSH_COUNT_CACHE;
|
2019-03-01 04:19:12 +01:00
|
|
|
if (count_cache_flush_assist) {
|
|
|
|
characteristics |= H_CPU_CHAR_BCCTR_FLUSH_ASSIST;
|
|
|
|
}
|
2019-03-01 04:19:11 +01:00
|
|
|
break;
|
2018-01-19 06:00:05 +01:00
|
|
|
default: /* broken */
|
|
|
|
assert(safe_indirect_branch == SPAPR_CAP_BROKEN);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
args[0] = characteristics;
|
|
|
|
args[1] = behaviour;
|
2018-12-21 01:34:48 +01:00
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
static target_ulong h_update_dt(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
2018-12-21 01:34:48 +01:00
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
target_ulong dt = ppc64_phys_to_real(args[0]);
|
|
|
|
struct fdt_header hdr = { 0 };
|
|
|
|
unsigned cb;
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
2018-12-21 01:34:48 +01:00
|
|
|
void *fdt;
|
|
|
|
|
|
|
|
cpu_physical_memory_read(dt, &hdr, sizeof(hdr));
|
|
|
|
cb = fdt32_to_cpu(hdr.totalsize);
|
|
|
|
|
|
|
|
if (!smc->update_dt_enabled) {
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check that the fdt did not grow out of proportion */
|
|
|
|
if (cb > spapr->fdt_initial_size * 2) {
|
|
|
|
trace_spapr_update_dt_failed_size(spapr->fdt_initial_size, cb,
|
|
|
|
fdt32_to_cpu(hdr.magic));
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
fdt = g_malloc0(cb);
|
|
|
|
cpu_physical_memory_read(dt, fdt, cb);
|
|
|
|
|
|
|
|
/* Check the fdt consistency */
|
|
|
|
if (fdt_check_full(fdt, cb)) {
|
|
|
|
trace_spapr_update_dt_failed_check(spapr->fdt_initial_size, cb,
|
|
|
|
fdt32_to_cpu(hdr.magic));
|
|
|
|
return H_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
g_free(spapr->fdt_blob);
|
|
|
|
spapr->fdt_size = cb;
|
|
|
|
spapr->fdt_blob = fdt;
|
|
|
|
trace_spapr_update_dt(cb);
|
2018-01-19 06:00:05 +01:00
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2011-05-10 08:06:21 +02:00
|
|
|
static spapr_hcall_fn papr_hypercall_table[(MAX_HCALL_OPCODE / 4) + 1];
|
|
|
|
static spapr_hcall_fn kvmppc_hypercall_table[KVMPPC_HCALL_MAX - KVMPPC_HCALL_BASE + 1];
|
spapr: initial implementation for H_TPM_COMM/spapr-tpm-proxy
This implements the H_TPM_COMM hypercall, which is used by an
Ultravisor to pass TPM commands directly to the host's TPM device, or
a TPM Resource Manager associated with the device.
This also introduces a new virtual device, spapr-tpm-proxy, which
is used to configure the host TPM path to be used to service
requests sent by H_TPM_COMM hcalls, for example:
-device spapr-tpm-proxy,id=tpmp0,host-path=/dev/tpmrm0
By default, no spapr-tpm-proxy will be created, and hcalls will return
H_FUNCTION.
The full specification for this hypercall can be found in
docs/specs/ppc-spapr-uv-hcalls.txt
Since SVM-related hcalls like H_TPM_COMM use a reserved range of
0xEF00-0xEF80, we introduce a separate hcall table here to handle
them.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com
Message-Id: <20190717205842.17827-3-mdroth@linux.vnet.ibm.com>
[dwg: Corrected #include for upstream change]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-17 22:58:42 +02:00
|
|
|
static spapr_hcall_fn svm_hypercall_table[(SVM_HCALL_MAX - SVM_HCALL_BASE) / 4 + 1];
|
2011-04-01 06:15:20 +02:00
|
|
|
|
|
|
|
void spapr_register_hypercall(target_ulong opcode, spapr_hcall_fn fn)
|
|
|
|
{
|
2011-04-01 06:15:23 +02:00
|
|
|
spapr_hcall_fn *slot;
|
|
|
|
|
|
|
|
if (opcode <= MAX_HCALL_OPCODE) {
|
|
|
|
assert((opcode & 0x3) == 0);
|
2011-04-01 06:15:20 +02:00
|
|
|
|
2011-04-01 06:15:23 +02:00
|
|
|
slot = &papr_hypercall_table[opcode / 4];
|
spapr: initial implementation for H_TPM_COMM/spapr-tpm-proxy
This implements the H_TPM_COMM hypercall, which is used by an
Ultravisor to pass TPM commands directly to the host's TPM device, or
a TPM Resource Manager associated with the device.
This also introduces a new virtual device, spapr-tpm-proxy, which
is used to configure the host TPM path to be used to service
requests sent by H_TPM_COMM hcalls, for example:
-device spapr-tpm-proxy,id=tpmp0,host-path=/dev/tpmrm0
By default, no spapr-tpm-proxy will be created, and hcalls will return
H_FUNCTION.
The full specification for this hypercall can be found in
docs/specs/ppc-spapr-uv-hcalls.txt
Since SVM-related hcalls like H_TPM_COMM use a reserved range of
0xEF00-0xEF80, we introduce a separate hcall table here to handle
them.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com
Message-Id: <20190717205842.17827-3-mdroth@linux.vnet.ibm.com>
[dwg: Corrected #include for upstream change]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-17 22:58:42 +02:00
|
|
|
} else if (opcode >= SVM_HCALL_BASE && opcode <= SVM_HCALL_MAX) {
|
|
|
|
/* we only have SVM-related hcall numbers assigned in multiples of 4 */
|
|
|
|
assert((opcode & 0x3) == 0);
|
|
|
|
|
|
|
|
slot = &svm_hypercall_table[(opcode - SVM_HCALL_BASE) / 4];
|
2011-04-01 06:15:23 +02:00
|
|
|
} else {
|
|
|
|
assert((opcode >= KVMPPC_HCALL_BASE) && (opcode <= KVMPPC_HCALL_MAX));
|
2011-04-01 06:15:20 +02:00
|
|
|
|
2011-04-01 06:15:23 +02:00
|
|
|
slot = &kvmppc_hypercall_table[opcode - KVMPPC_HCALL_BASE];
|
|
|
|
}
|
2011-04-01 06:15:20 +02:00
|
|
|
|
2012-10-08 20:17:36 +02:00
|
|
|
assert(!(*slot));
|
2011-04-01 06:15:23 +02:00
|
|
|
*slot = fn;
|
2011-04-01 06:15:20 +02:00
|
|
|
}
|
|
|
|
|
2012-05-03 06:13:14 +02:00
|
|
|
target_ulong spapr_hypercall(PowerPCCPU *cpu, target_ulong opcode,
|
2011-04-01 06:15:20 +02:00
|
|
|
target_ulong *args)
|
|
|
|
{
|
spapr: Use CamelCase properly
The qemu coding standard is to use CamelCase for type and structure names,
and the pseries code follows that... sort of. There are quite a lot of
places where we bend the rules in order to preserve the capitalization of
internal acronyms like "PHB", "TCE", "DIMM" and most commonly "sPAPR".
That was a bad idea - it frequently leads to names ending up with hard to
read clusters of capital letters, and means they don't catch the eye as
type identifiers, which is kind of the point of the CamelCase convention in
the first place.
In short, keeping type identifiers look like CamelCase is more important
than preserving standard capitalization of internal "words". So, this
patch renames a heap of spapr internal type names to a more standard
CamelCase.
In addition to case changes, we also make some other identifier renames:
VIOsPAPR* -> SpaprVio*
The reverse word ordering was only ever used to mitigate the capital
cluster, so revert to the natural ordering.
VIOsPAPRVTYDevice -> SpaprVioVty
VIOsPAPRVLANDevice -> SpaprVioVlan
Brevity, since the "Device" didn't add useful information
sPAPRDRConnector -> SpaprDrc
sPAPRDRConnectorClass -> SpaprDrcClass
Brevity, and makes it clearer this is the same thing as a "DRC"
mentioned in many other places in the code
This is 100% a mechanical search-and-replace patch. It will, however,
conflict with essentially any and all outstanding patches touching the
spapr code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-06 05:35:37 +01:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
|
2015-07-02 08:23:04 +02:00
|
|
|
|
2011-04-01 06:15:20 +02:00
|
|
|
if ((opcode <= MAX_HCALL_OPCODE)
|
|
|
|
&& ((opcode & 0x3) == 0)) {
|
2011-04-01 06:15:23 +02:00
|
|
|
spapr_hcall_fn fn = papr_hypercall_table[opcode / 4];
|
|
|
|
|
spapr: initial implementation for H_TPM_COMM/spapr-tpm-proxy
This implements the H_TPM_COMM hypercall, which is used by an
Ultravisor to pass TPM commands directly to the host's TPM device, or
a TPM Resource Manager associated with the device.
This also introduces a new virtual device, spapr-tpm-proxy, which
is used to configure the host TPM path to be used to service
requests sent by H_TPM_COMM hcalls, for example:
-device spapr-tpm-proxy,id=tpmp0,host-path=/dev/tpmrm0
By default, no spapr-tpm-proxy will be created, and hcalls will return
H_FUNCTION.
The full specification for this hypercall can be found in
docs/specs/ppc-spapr-uv-hcalls.txt
Since SVM-related hcalls like H_TPM_COMM use a reserved range of
0xEF00-0xEF80, we introduce a separate hcall table here to handle
them.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com
Message-Id: <20190717205842.17827-3-mdroth@linux.vnet.ibm.com>
[dwg: Corrected #include for upstream change]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-07-17 22:58:42 +02:00
|
|
|
if (fn) {
|
|
|
|
return fn(cpu, spapr, opcode, args);
|
|
|
|
}
|
|
|
|
} else if ((opcode >= SVM_HCALL_BASE) &&
|
|
|
|
(opcode <= SVM_HCALL_MAX)) {
|
|
|
|
spapr_hcall_fn fn = svm_hypercall_table[(opcode - SVM_HCALL_BASE) / 4];
|
|
|
|
|
2011-04-01 06:15:23 +02:00
|
|
|
if (fn) {
|
2012-05-03 06:23:01 +02:00
|
|
|
return fn(cpu, spapr, opcode, args);
|
2011-04-01 06:15:23 +02:00
|
|
|
}
|
|
|
|
} else if ((opcode >= KVMPPC_HCALL_BASE) &&
|
|
|
|
(opcode <= KVMPPC_HCALL_MAX)) {
|
|
|
|
spapr_hcall_fn fn = kvmppc_hypercall_table[opcode - KVMPPC_HCALL_BASE];
|
2011-04-01 06:15:20 +02:00
|
|
|
|
|
|
|
if (fn) {
|
2012-05-03 06:23:01 +02:00
|
|
|
return fn(cpu, spapr, opcode, args);
|
2011-04-01 06:15:20 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-01 03:29:02 +02:00
|
|
|
qemu_log_mask(LOG_UNIMP, "Unimplemented SPAPR hcall 0x" TARGET_FMT_lx "\n",
|
|
|
|
opcode);
|
2011-04-01 06:15:20 +02:00
|
|
|
return H_FUNCTION;
|
|
|
|
}
|
2011-04-01 06:15:22 +02:00
|
|
|
|
2021-05-06 18:39:38 +02:00
|
|
|
#ifndef CONFIG_TCG
|
|
|
|
static target_ulong h_softmmu(PowerPCCPU *cpu, SpaprMachineState *spapr,
|
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
g_assert_not_reached();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void hypercall_register_softmmu(void)
|
2011-04-01 06:15:22 +02:00
|
|
|
{
|
|
|
|
/* hcall-pft */
|
2021-05-06 18:39:38 +02:00
|
|
|
spapr_register_hypercall(H_ENTER, h_softmmu);
|
|
|
|
spapr_register_hypercall(H_REMOVE, h_softmmu);
|
|
|
|
spapr_register_hypercall(H_PROTECT, h_softmmu);
|
|
|
|
spapr_register_hypercall(H_READ, h_softmmu);
|
2011-04-01 06:15:23 +02:00
|
|
|
|
2011-08-31 17:50:50 +02:00
|
|
|
/* hcall-bulk */
|
2021-05-06 18:39:38 +02:00
|
|
|
spapr_register_hypercall(H_BULK_REMOVE, h_softmmu);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static void hypercall_register_softmmu(void)
|
|
|
|
{
|
|
|
|
/* DO NOTHING */
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static void hypercall_register_types(void)
|
|
|
|
{
|
|
|
|
hypercall_register_softmmu();
|
2011-08-31 17:50:50 +02:00
|
|
|
|
2017-05-12 07:46:11 +02:00
|
|
|
/* hcall-hpt-resize */
|
|
|
|
spapr_register_hypercall(H_RESIZE_HPT_PREPARE, h_resize_hpt_prepare);
|
|
|
|
spapr_register_hypercall(H_RESIZE_HPT_COMMIT, h_resize_hpt_commit);
|
|
|
|
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
/* hcall-splpar */
|
|
|
|
spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
|
|
|
|
spapr_register_hypercall(H_CEDE, h_cede);
|
2019-07-18 05:42:13 +02:00
|
|
|
spapr_register_hypercall(H_CONFER, h_confer);
|
2019-07-18 05:42:12 +02:00
|
|
|
spapr_register_hypercall(H_PROD, h_prod);
|
|
|
|
|
2019-07-18 05:42:14 +02:00
|
|
|
/* hcall-join */
|
|
|
|
spapr_register_hypercall(H_JOIN, h_join);
|
|
|
|
|
2016-12-05 06:50:21 +01:00
|
|
|
spapr_register_hypercall(H_SIGNAL_SYS_RESET, h_signal_sys_reset);
|
Implement PAPR VPA functions for pSeries shared processor partitions
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: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 06:15:33 +02:00
|
|
|
|
2016-02-11 13:47:18 +01:00
|
|
|
/* processor register resource access h-calls */
|
|
|
|
spapr_register_hypercall(H_SET_SPRG0, h_set_sprg0);
|
2016-02-11 13:47:19 +01:00
|
|
|
spapr_register_hypercall(H_SET_DABR, h_set_dabr);
|
2016-02-11 13:47:20 +01:00
|
|
|
spapr_register_hypercall(H_SET_XDABR, h_set_xdabr);
|
2016-02-18 10:15:54 +01:00
|
|
|
spapr_register_hypercall(H_PAGE_INIT, h_page_init);
|
2016-02-11 13:47:18 +01:00
|
|
|
spapr_register_hypercall(H_SET_MODE, h_set_mode);
|
|
|
|
|
2017-03-20 00:46:45 +01:00
|
|
|
/* In Memory Table MMU h-calls */
|
|
|
|
spapr_register_hypercall(H_CLEAN_SLB, h_clean_slb);
|
|
|
|
spapr_register_hypercall(H_INVALIDATE_PID, h_invalidate_pid);
|
|
|
|
spapr_register_hypercall(H_REGISTER_PROC_TBL, h_register_process_table);
|
|
|
|
|
2018-01-19 06:00:05 +01:00
|
|
|
/* hcall-get-cpu-characteristics */
|
|
|
|
spapr_register_hypercall(H_GET_CPU_CHARACTERISTICS,
|
|
|
|
h_get_cpu_characteristics);
|
|
|
|
|
2011-08-10 16:44:20 +02:00
|
|
|
/* "debugger" hcalls (also used by SLOF). Note: We do -not- differenciate
|
|
|
|
* here between the "CI" and the "CACHE" variants, they will use whatever
|
|
|
|
* mapping attributes qemu is using. When using KVM, the kernel will
|
|
|
|
* enforce the attributes more strongly
|
|
|
|
*/
|
|
|
|
spapr_register_hypercall(H_LOGICAL_CI_LOAD, h_logical_load);
|
|
|
|
spapr_register_hypercall(H_LOGICAL_CI_STORE, h_logical_store);
|
|
|
|
spapr_register_hypercall(H_LOGICAL_CACHE_LOAD, h_logical_load);
|
|
|
|
spapr_register_hypercall(H_LOGICAL_CACHE_STORE, h_logical_store);
|
|
|
|
spapr_register_hypercall(H_LOGICAL_ICBI, h_logical_icbi);
|
|
|
|
spapr_register_hypercall(H_LOGICAL_DCBF, h_logical_dcbf);
|
2012-06-18 22:21:37 +02:00
|
|
|
spapr_register_hypercall(KVMPPC_H_LOGICAL_MEMOP, h_logical_memop);
|
2011-08-10 16:44:20 +02:00
|
|
|
|
2011-04-01 06:15:23 +02:00
|
|
|
/* qemu/KVM-PPC specific hcalls */
|
|
|
|
spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
|
2013-08-19 13:04:20 +02:00
|
|
|
|
2014-05-23 04:26:54 +02:00
|
|
|
/* ibm,client-architecture-support support */
|
|
|
|
spapr_register_hypercall(KVMPPC_H_CAS, h_client_architecture_support);
|
2018-12-19 17:35:41 +01:00
|
|
|
|
2018-12-21 01:34:48 +01:00
|
|
|
spapr_register_hypercall(KVMPPC_H_UPDATE_DT, h_update_dt);
|
2011-04-01 06:15:22 +02:00
|
|
|
}
|
2012-02-09 15:20:55 +01:00
|
|
|
|
|
|
|
type_init(hypercall_register_types)
|