2011-04-01 08:15:20 +04:00
|
|
|
/*
|
|
|
|
* QEMU PowerPC pSeries Logical Partition (aka sPAPR) hardware System Emulator
|
|
|
|
*
|
|
|
|
* Copyright (c) 2004-2007 Fabrice Bellard
|
|
|
|
* Copyright (c) 2007 Jocelyn Mayer
|
|
|
|
* Copyright (c) 2010 David Gibson, IBM Corporation.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2019-05-23 17:35:08 +03:00
|
|
|
|
2016-01-26 21:16:58 +03:00
|
|
|
#include "qemu/osdep.h"
|
2020-10-28 14:36:57 +03:00
|
|
|
#include "qemu/datadir.h"
|
2022-02-26 21:07:23 +03:00
|
|
|
#include "qemu/memalign.h"
|
2022-07-12 16:51:14 +03:00
|
|
|
#include "qemu/guest-random.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 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2021-03-02 17:10:19 +03:00
|
|
|
#include "qapi/qapi-events-machine.h"
|
2021-09-07 03:47:54 +03:00
|
|
|
#include "qapi/qapi-events-qdev.h"
|
2017-08-18 08:50:22 +03:00
|
|
|
#include "qapi/visitor.h"
|
2012-12-17 21:20:04 +04:00
|
|
|
#include "sysemu/sysemu.h"
|
2019-08-12 08:23:55 +03:00
|
|
|
#include "sysemu/hostmem.h"
|
2015-02-08 21:51:16 +03:00
|
|
|
#include "sysemu/numa.h"
|
2019-03-01 22:32:37 +03:00
|
|
|
#include "sysemu/qtest.h"
|
2019-08-12 08:23:38 +03:00
|
|
|
#include "sysemu/reset.h"
|
2019-08-12 08:23:59 +03:00
|
|
|
#include "sysemu/runstate.h"
|
2015-12-15 15:16:16 +03:00
|
|
|
#include "qemu/log.h"
|
2014-03-17 06:40:27 +04:00
|
|
|
#include "hw/fw-path-provider.h"
|
2011-04-01 08:15:20 +04:00
|
|
|
#include "elf.h"
|
2012-10-24 10:43:34 +04:00
|
|
|
#include "net/net.h"
|
2015-09-01 04:25:35 +03:00
|
|
|
#include "sysemu/device_tree.h"
|
2012-12-17 21:20:04 +04:00
|
|
|
#include "sysemu/cpus.h"
|
2017-01-10 13:59:55 +03:00
|
|
|
#include "sysemu/hw_accel.h"
|
2011-09-30 01:39:10 +04:00
|
|
|
#include "kvm_ppc.h"
|
2017-04-24 20:02:44 +03:00
|
|
|
#include "migration/misc.h"
|
2019-08-12 08:23:39 +03:00
|
|
|
#include "migration/qemu-file-types.h"
|
2017-04-24 19:53:30 +03:00
|
|
|
#include "migration/global_state.h"
|
2017-04-24 14:42:55 +03:00
|
|
|
#include "migration/register.h"
|
2020-01-30 21:44:22 +03:00
|
|
|
#include "migration/blocker.h"
|
2013-07-18 23:33:01 +04:00
|
|
|
#include "mmu-hash64.h"
|
2017-03-20 02:46:46 +03:00
|
|
|
#include "mmu-book3s-v3.h"
|
2017-11-17 08:39:00 +03:00
|
|
|
#include "cpu-models.h"
|
2019-07-09 18:20:52 +03:00
|
|
|
#include "hw/core/cpu.h"
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/ppc/ppc.h"
|
2011-04-01 08:15:20 +04:00
|
|
|
#include "hw/loader.h"
|
|
|
|
|
2016-07-25 17:24:41 +03:00
|
|
|
#include "hw/ppc/fdt.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/ppc/spapr.h"
|
2023-06-20 13:57:37 +03:00
|
|
|
#include "hw/ppc/spapr_nested.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/ppc/spapr_vio.h"
|
2022-12-13 15:35:49 +03:00
|
|
|
#include "hw/ppc/vof.h"
|
2019-08-12 08:23:51 +03:00
|
|
|
#include "hw/qdev-properties.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/pci-host/spapr.h"
|
2012-12-12 16:24:50 +04:00
|
|
|
#include "hw/pci/msi.h"
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/pci/pci.h"
|
2014-03-17 06:40:27 +04:00
|
|
|
#include "hw/scsi/scsi.h"
|
|
|
|
#include "hw/virtio/virtio-scsi.h"
|
2017-06-05 18:55:18 +03:00
|
|
|
#include "hw/virtio/vhost-scsi-common.h"
|
2011-08-09 19:57:37 +04:00
|
|
|
|
2018-03-16 11:19:13 +03:00
|
|
|
#include "exec/ram_addr.h"
|
2012-08-16 06:03:56 +04:00
|
|
|
#include "hw/usb.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/config-file.h"
|
2013-12-23 19:40:40 +04:00
|
|
|
#include "qemu/error-report.h"
|
2014-05-23 06:26:54 +04:00
|
|
|
#include "trace.h"
|
2014-08-20 16:16:36 +04:00
|
|
|
#include "hw/nmi.h"
|
2017-02-27 17:29:32 +03:00
|
|
|
#include "hw/intc/intc.h"
|
2011-10-03 14:56:38 +04:00
|
|
|
|
2016-06-10 03:59:03 +03:00
|
|
|
#include "hw/ppc/spapr_cpu_core.h"
|
2018-04-23 19:51:16 +03:00
|
|
|
#include "hw/mem/memory-device.h"
|
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 23:58:42 +03:00
|
|
|
#include "hw/ppc/spapr_tpm_proxy.h"
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
#include "hw/ppc/spapr_nvdimm.h"
|
2020-09-01 15:56:39 +03:00
|
|
|
#include "hw/ppc/spapr_numa.h"
|
2020-04-08 08:10:03 +03:00
|
|
|
#include "hw/ppc/pef.h"
|
2014-10-14 20:40:06 +04:00
|
|
|
|
2019-09-12 17:30:09 +03:00
|
|
|
#include "monitor/monitor.h"
|
|
|
|
|
2011-04-01 08:15:20 +04:00
|
|
|
#include <libfdt.h>
|
|
|
|
|
2012-01-11 23:46:28 +04:00
|
|
|
/* SLOF memory layout:
|
|
|
|
*
|
|
|
|
* SLOF raw image loaded at 0, copies its romfs right below the flat
|
|
|
|
* device-tree, then position SLOF itself 31M below that
|
|
|
|
*
|
|
|
|
* So we set FW_OVERHEAD to 40MB which should account for all of that
|
|
|
|
* and more
|
|
|
|
*
|
|
|
|
* We load our kernel at 4M, leaving space for SLOF initial image
|
|
|
|
*/
|
2021-03-31 05:51:23 +03:00
|
|
|
#define FDT_MAX_ADDR 0x80000000 /* FDT must stay below that */
|
Add SLOF-based partition firmware for pSeries machine, allowing more boot options
Currently, the emulated pSeries machine requires the use of the
-kernel parameter in order to explicitly load a guest kernel. This
means booting from the virtual disk, cdrom or network is not possible.
This patch addresses this limitation by inserting a within-partition
firmware image (derived from the "SLOF" free Open Firmware project).
If -kernel is not specified, qemu will now load the SLOF image, which
has access to the qemu boot device list through the device tree, and
can boot from any of the usual virtual devices.
In order to support the new firmware, an extension to the emulated
machine/hypervisor is necessary. Unlike Linux, which expects
multi-CPU entry to be handled kexec() style, the SLOF firmware expects
only one CPU to be active at entry, and to use a hypervisor RTAS
method to enable the other CPUs one by one.
This patch also implements this 'start-cpu' method, so that SLOF can
start the secondary CPUs and marshal them into the kexec() holding
pattern ready for entry into the guest OS. Linux should, and in the
future might directly use the start-cpu method to enable initially
disabled CPUs, but for now it does require kexec() entry.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 08:15:34 +04:00
|
|
|
#define FW_MAX_SIZE 0x400000
|
|
|
|
#define FW_FILE_NAME "slof.bin"
|
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 08:51:55 +03:00
|
|
|
#define FW_FILE_NAME_VOF "vof.bin"
|
2012-01-11 23:46:28 +04:00
|
|
|
#define FW_OVERHEAD 0x2800000
|
|
|
|
#define KERNEL_LOAD_ADDR FW_MAX_SIZE
|
Add SLOF-based partition firmware for pSeries machine, allowing more boot options
Currently, the emulated pSeries machine requires the use of the
-kernel parameter in order to explicitly load a guest kernel. This
means booting from the virtual disk, cdrom or network is not possible.
This patch addresses this limitation by inserting a within-partition
firmware image (derived from the "SLOF" free Open Firmware project).
If -kernel is not specified, qemu will now load the SLOF image, which
has access to the qemu boot device list through the device tree, and
can boot from any of the usual virtual devices.
In order to support the new firmware, an extension to the emulated
machine/hypervisor is necessary. Unlike Linux, which expects
multi-CPU entry to be handled kexec() style, the SLOF firmware expects
only one CPU to be active at entry, and to use a hypervisor RTAS
method to enable the other CPUs one by one.
This patch also implements this 'start-cpu' method, so that SLOF can
start the secondary CPUs and marshal them into the kexec() holding
pattern ready for entry into the guest OS. Linux should, and in the
future might directly use the start-cpu method to enable initially
disabled CPUs, but for now it does require kexec() entry.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 08:15:34 +04:00
|
|
|
|
2019-12-10 08:25:04 +03:00
|
|
|
#define MIN_RMA_SLOF (128 * MiB)
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2019-01-17 20:14:39 +03:00
|
|
|
#define PHANDLE_INTC 0x00001111
|
2011-08-04 01:02:17 +04:00
|
|
|
|
2018-02-14 22:40:53 +03:00
|
|
|
/* These two functions implement the VCPU id numbering: one to compute them
|
|
|
|
* all and one to identify thread 0 of a VCORE. Any change to the first one
|
|
|
|
* is likely to have an impact on the second one, so let's keep them close.
|
|
|
|
*/
|
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 07:35:37 +03:00
|
|
|
static int spapr_vcpu_id(SpaprMachineState *spapr, int cpu_index)
|
2018-02-14 22:40:53 +03:00
|
|
|
{
|
2019-05-18 23:54:22 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
unsigned int smp_threads = ms->smp.threads;
|
|
|
|
|
2018-02-27 18:23:07 +03:00
|
|
|
assert(spapr->vsmt);
|
2018-02-14 22:40:53 +03:00
|
|
|
return
|
|
|
|
(cpu_index / smp_threads) * spapr->vsmt + cpu_index % smp_threads;
|
|
|
|
}
|
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 07:35:37 +03:00
|
|
|
static bool spapr_is_thread0_in_vcore(SpaprMachineState *spapr,
|
2018-02-14 22:40:53 +03:00
|
|
|
PowerPCCPU *cpu)
|
|
|
|
{
|
2018-02-27 18:23:07 +03:00
|
|
|
assert(spapr->vsmt);
|
2018-02-14 22:40:53 +03:00
|
|
|
return spapr_get_vcpu_id(cpu) % spapr->vsmt == 0;
|
|
|
|
}
|
|
|
|
|
2017-06-14 16:29:19 +03:00
|
|
|
static bool pre_2_10_vmstate_dummy_icp_needed(void *opaque)
|
|
|
|
{
|
|
|
|
/* Dummy entries correspond to unused ICPState objects in older QEMUs,
|
|
|
|
* and newer QEMUs don't even have them. In both cases, we don't want
|
|
|
|
* to send anything on the wire.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription pre_2_10_vmstate_dummy_icp = {
|
2023-10-20 12:07:25 +03:00
|
|
|
/*
|
|
|
|
* Hack ahead. We can't have two devices with the same name and
|
|
|
|
* instance id. So I rename this to pass make check.
|
|
|
|
* Real help from people who knows the hardware is needed.
|
|
|
|
*/
|
2017-06-14 16:29:19 +03:00
|
|
|
.name = "icp/server",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = pre_2_10_vmstate_dummy_icp_needed,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
2017-06-14 16:29:19 +03:00
|
|
|
VMSTATE_UNUSED(4), /* uint32_t xirr */
|
|
|
|
VMSTATE_UNUSED(1), /* uint8_t pending_priority */
|
|
|
|
VMSTATE_UNUSED(1), /* uint8_t mfrr */
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2023-10-20 12:07:25 +03:00
|
|
|
/*
|
|
|
|
* See comment in hw/intc/xics.c:icp_realize()
|
|
|
|
*
|
|
|
|
* You have to remove vmstate_replace_hack_for_ppc() when you remove
|
|
|
|
* the machine types that need the following function.
|
|
|
|
*/
|
2017-06-14 16:29:19 +03:00
|
|
|
static void pre_2_10_vmstate_register_dummy_icp(int i)
|
|
|
|
{
|
|
|
|
vmstate_register(NULL, i, &pre_2_10_vmstate_dummy_icp,
|
|
|
|
(void *)(uintptr_t) i);
|
|
|
|
}
|
|
|
|
|
2023-10-20 12:07:25 +03:00
|
|
|
/*
|
|
|
|
* See comment in hw/intc/xics.c:icp_realize()
|
|
|
|
*
|
|
|
|
* You have to remove vmstate_replace_hack_for_ppc() when you remove
|
|
|
|
* the machine types that need the following function.
|
|
|
|
*/
|
2017-06-14 16:29:19 +03:00
|
|
|
static void pre_2_10_vmstate_unregister_dummy_icp(int i)
|
|
|
|
{
|
2023-10-20 12:07:25 +03:00
|
|
|
/*
|
|
|
|
* This used to be:
|
|
|
|
*
|
|
|
|
* vmstate_unregister(NULL, &pre_2_10_vmstate_dummy_icp,
|
|
|
|
* (void *)(uintptr_t) i);
|
|
|
|
*/
|
2017-06-14 16:29:19 +03: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 07:35:37 +03:00
|
|
|
int spapr_max_server_number(SpaprMachineState *spapr)
|
2017-06-14 16:29:19 +03:00
|
|
|
{
|
2019-05-18 23:54:22 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
|
2018-02-27 18:23:07 +03:00
|
|
|
assert(spapr->vsmt);
|
2019-05-18 23:54:22 +03:00
|
|
|
return DIV_ROUND_UP(ms->smp.max_cpus * spapr->vsmt, ms->smp.threads);
|
2017-06-14 16:29:19 +03:00
|
|
|
}
|
|
|
|
|
2014-05-23 06:26:51 +04:00
|
|
|
static int spapr_fixup_cpu_smt_dt(void *fdt, int offset, PowerPCCPU *cpu,
|
|
|
|
int smt_threads)
|
|
|
|
{
|
|
|
|
int i, ret = 0;
|
2022-08-19 18:39:26 +03:00
|
|
|
g_autofree uint32_t *servers_prop = g_new(uint32_t, smt_threads);
|
|
|
|
g_autofree uint32_t *gservers_prop = g_new(uint32_t, smt_threads * 2);
|
2018-02-14 22:40:44 +03:00
|
|
|
int index = spapr_get_vcpu_id(cpu);
|
2014-05-23 06:26:51 +04:00
|
|
|
|
2016-10-28 14:09:37 +03:00
|
|
|
if (cpu->compat_pvr) {
|
|
|
|
ret = fdt_setprop_cell(fdt, offset, "cpu-version", cpu->compat_pvr);
|
2014-05-23 06:26:52 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-23 06:26:51 +04:00
|
|
|
/* Build interrupt servers and gservers properties */
|
|
|
|
for (i = 0; i < smt_threads; i++) {
|
|
|
|
servers_prop[i] = cpu_to_be32(index + i);
|
|
|
|
/* Hack, direct the group queues back to cpu 0 */
|
|
|
|
gservers_prop[i*2] = cpu_to_be32(index + i);
|
|
|
|
gservers_prop[i*2 + 1] = 0;
|
|
|
|
}
|
|
|
|
ret = fdt_setprop(fdt, offset, "ibm,ppc-interrupt-server#s",
|
2022-08-19 18:39:26 +03:00
|
|
|
servers_prop, sizeof(*servers_prop) * smt_threads);
|
2014-05-23 06:26:51 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
ret = fdt_setprop(fdt, offset, "ibm,ppc-interrupt-gserver#s",
|
2022-08-19 18:39:26 +03:00
|
|
|
gservers_prop, sizeof(*gservers_prop) * smt_threads * 2);
|
2014-05-23 06:26:51 +04:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static void spapr_dt_pa_features(SpaprMachineState *spapr,
|
|
|
|
PowerPCCPU *cpu,
|
|
|
|
void *fdt, int offset)
|
2017-03-20 02:46:47 +03:00
|
|
|
{
|
|
|
|
uint8_t pa_features_206[] = { 6, 0,
|
|
|
|
0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
|
|
|
|
uint8_t pa_features_207[] = { 24, 0,
|
|
|
|
0xf6, 0x1f, 0xc7, 0xc0, 0x80, 0xf0,
|
|
|
|
0x80, 0x00, 0x00, 0x00, 0x00, 0x00,
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x80, 0x00,
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x00, 0x00 };
|
2017-03-23 06:46:00 +03:00
|
|
|
uint8_t pa_features_300[] = { 66, 0,
|
|
|
|
/* 0: MMU|FPU|SLB|RUN|DABR|NX, 1: fri[nzpm]|DABRX|SPRG3|SLB0|PP110 */
|
|
|
|
/* 2: VPM|DS205|PPR|DS202|DS206, 3: LSD|URG, SSO, 5: LE|CFAR|EB|LSQ */
|
|
|
|
0xf6, 0x1f, 0xc7, 0xc0, 0x80, 0xf0, /* 0 - 5 */
|
|
|
|
/* 6: DS207 */
|
|
|
|
0x80, 0x00, 0x00, 0x00, 0x00, 0x00, /* 6 - 11 */
|
|
|
|
/* 16: Vector */
|
2017-03-20 02:46:47 +03:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x80, 0x00, /* 12 - 17 */
|
2017-03-23 06:46:00 +03:00
|
|
|
/* 18: Vec. Scalar, 20: Vec. XOR, 22: HTM */
|
2017-05-09 08:03:12 +03:00
|
|
|
0x80, 0x00, 0x80, 0x00, 0x00, 0x00, /* 18 - 23 */
|
2017-03-23 06:46:00 +03:00
|
|
|
/* 24: Ext. Dec, 26: 64 bit ftrs, 28: PM ftrs */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x80, 0x00, /* 24 - 29 */
|
|
|
|
/* 30: MMR, 32: LE atomic, 34: EBB + ext EBB */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0xC0, 0x00, /* 30 - 35 */
|
|
|
|
/* 36: SPR SO, 38: Copy/Paste, 40: Radix MMU */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x80, 0x00, /* 36 - 41 */
|
|
|
|
/* 42: PM, 44: PC RA, 46: SC vec'd */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x80, 0x00, /* 42 - 47 */
|
|
|
|
/* 48: SIMD, 50: QP BFP, 52: String */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x80, 0x00, /* 48 - 53 */
|
|
|
|
/* 54: DecFP, 56: DecI, 58: SHA */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x80, 0x00, /* 54 - 59 */
|
|
|
|
/* 60: NM atomic, 62: RNG */
|
|
|
|
0x80, 0x00, 0x80, 0x00, 0x00, 0x00, /* 60 - 65 */
|
|
|
|
};
|
2017-11-17 08:39:00 +03:00
|
|
|
uint8_t *pa_features = NULL;
|
2017-03-20 02:46:47 +03:00
|
|
|
size_t pa_size;
|
|
|
|
|
2017-11-17 08:39:00 +03:00
|
|
|
if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_06, 0, cpu->compat_pvr)) {
|
2017-03-20 02:46:47 +03:00
|
|
|
pa_features = pa_features_206;
|
|
|
|
pa_size = sizeof(pa_features_206);
|
2017-11-17 08:39:00 +03:00
|
|
|
}
|
|
|
|
if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_07, 0, cpu->compat_pvr)) {
|
2017-03-20 02:46:47 +03:00
|
|
|
pa_features = pa_features_207;
|
|
|
|
pa_size = sizeof(pa_features_207);
|
2017-11-17 08:39:00 +03:00
|
|
|
}
|
|
|
|
if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_3_00, 0, cpu->compat_pvr)) {
|
2017-03-20 02:46:47 +03:00
|
|
|
pa_features = pa_features_300;
|
|
|
|
pa_size = sizeof(pa_features_300);
|
2017-11-17 08:39:00 +03:00
|
|
|
}
|
|
|
|
if (!pa_features) {
|
2017-03-20 02:46:47 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-03-23 06:32:48 +03:00
|
|
|
if (ppc_hash64_has(cpu, PPC_HASH64_CI_LARGEPAGE)) {
|
2017-03-20 02:46:47 +03:00
|
|
|
/*
|
|
|
|
* Note: we keep CI large pages off by default because a 64K capable
|
|
|
|
* guest provisioned with large pages might otherwise try to map a qemu
|
|
|
|
* framebuffer (or other kind of memory mapped PCI BAR) using 64K pages
|
|
|
|
* even if that qemu runs on a 4k host.
|
|
|
|
* We dd this bit back here if we are confident this is not an issue
|
|
|
|
*/
|
|
|
|
pa_features[3] |= 0x20;
|
|
|
|
}
|
2018-01-12 08:33:43 +03:00
|
|
|
if ((spapr_get_cap(spapr, SPAPR_CAP_HTM) != 0) && pa_size > 24) {
|
2017-03-20 02:46:47 +03:00
|
|
|
pa_features[24] |= 0x80; /* Transactional memory support */
|
|
|
|
}
|
2019-08-28 06:59:27 +03:00
|
|
|
if (spapr->cas_pre_isa3_guest && pa_size > 40) {
|
2017-03-20 02:46:49 +03:00
|
|
|
/* Workaround for broken kernels that attempt (guest) radix
|
|
|
|
* mode when they can't handle it, if they see the radix bit set
|
|
|
|
* in pa-features. So hide it from them. */
|
|
|
|
pa_features[40 + 2] &= ~0x80; /* Radix MMU */
|
|
|
|
}
|
2017-03-20 02:46:47 +03:00
|
|
|
|
|
|
|
_FDT((fdt_setprop(fdt, offset, "ibm,pa-features", pa_features, pa_size)));
|
|
|
|
}
|
|
|
|
|
2017-09-06 21:43:05 +03:00
|
|
|
static hwaddr spapr_node0_size(MachineState *machine)
|
2014-07-03 07:10:06 +04:00
|
|
|
{
|
2019-08-09 09:57:22 +03:00
|
|
|
if (machine->numa_state->num_nodes) {
|
2014-07-03 07:10:06 +04:00
|
|
|
int i;
|
2019-08-09 09:57:22 +03:00
|
|
|
for (i = 0; i < machine->numa_state->num_nodes; ++i) {
|
2019-08-09 09:57:24 +03:00
|
|
|
if (machine->numa_state->nodes[i].node_mem) {
|
|
|
|
return MIN(pow2floor(machine->numa_state->nodes[i].node_mem),
|
2015-07-02 09:23:05 +03:00
|
|
|
machine->ram_size);
|
2014-07-03 07:10:06 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-07-02 09:23:05 +03:00
|
|
|
return machine->ram_size;
|
2014-07-03 07:10:06 +04:00
|
|
|
}
|
|
|
|
|
2014-05-27 09:36:29 +04:00
|
|
|
static void add_str(GString *s, const gchar *s1)
|
|
|
|
{
|
|
|
|
g_string_append_len(s, s1, strlen(s1) + 1);
|
|
|
|
}
|
2012-09-12 20:57:12 +04:00
|
|
|
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
static int spapr_dt_memory_node(SpaprMachineState *spapr, void *fdt, int nodeid,
|
|
|
|
hwaddr start, hwaddr size)
|
2014-07-03 07:10:02 +04:00
|
|
|
{
|
|
|
|
char mem_name[32];
|
|
|
|
uint64_t mem_reg_property[2];
|
|
|
|
int off;
|
|
|
|
|
|
|
|
mem_reg_property[0] = cpu_to_be64(start);
|
|
|
|
mem_reg_property[1] = cpu_to_be64(size);
|
|
|
|
|
2019-09-03 05:34:34 +03:00
|
|
|
sprintf(mem_name, "memory@%" HWADDR_PRIx, start);
|
2014-07-03 07:10:02 +04:00
|
|
|
off = fdt_add_subnode(fdt, 0, mem_name);
|
|
|
|
_FDT(off);
|
|
|
|
_FDT((fdt_setprop_string(fdt, off, "device_type", "memory")));
|
|
|
|
_FDT((fdt_setprop(fdt, off, "reg", mem_reg_property,
|
|
|
|
sizeof(mem_reg_property))));
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
spapr_numa_write_associativity_dt(spapr, fdt, off, nodeid);
|
2015-07-13 03:34:00 +03:00
|
|
|
return off;
|
2014-07-03 07:10:02 +04:00
|
|
|
}
|
|
|
|
|
2017-12-05 18:41:17 +03:00
|
|
|
static uint32_t spapr_pc_dimm_node(MemoryDeviceInfoList *list, ram_addr_t addr)
|
|
|
|
{
|
|
|
|
MemoryDeviceInfoList *info;
|
|
|
|
|
|
|
|
for (info = list; info; info = info->next) {
|
|
|
|
MemoryDeviceInfo *value = info->value;
|
|
|
|
|
|
|
|
if (value && value->type == MEMORY_DEVICE_INFO_KIND_DIMM) {
|
|
|
|
PCDIMMDeviceInfo *pcdimm_info = value->u.dimm.data;
|
|
|
|
|
2018-07-10 04:40:52 +03:00
|
|
|
if (addr >= pcdimm_info->addr &&
|
2017-12-05 18:41:17 +03:00
|
|
|
addr < (pcdimm_info->addr + pcdimm_info->size)) {
|
|
|
|
return pcdimm_info->node;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2018-04-19 09:47:35 +03:00
|
|
|
struct sPAPRDrconfCellV2 {
|
|
|
|
uint32_t seq_lmbs;
|
|
|
|
uint64_t base_addr;
|
|
|
|
uint32_t drc_index;
|
|
|
|
uint32_t aa_index;
|
|
|
|
uint32_t flags;
|
|
|
|
} QEMU_PACKED;
|
|
|
|
|
|
|
|
typedef struct DrconfCellQueue {
|
|
|
|
struct sPAPRDrconfCellV2 cell;
|
|
|
|
QSIMPLEQ_ENTRY(DrconfCellQueue) entry;
|
|
|
|
} DrconfCellQueue;
|
|
|
|
|
|
|
|
static DrconfCellQueue *
|
|
|
|
spapr_get_drconf_cell(uint32_t seq_lmbs, uint64_t base_addr,
|
|
|
|
uint32_t drc_index, uint32_t aa_index,
|
|
|
|
uint32_t flags)
|
2015-07-13 03:34:00 +03:00
|
|
|
{
|
2018-04-19 09:47:35 +03:00
|
|
|
DrconfCellQueue *elem;
|
|
|
|
|
|
|
|
elem = g_malloc0(sizeof(*elem));
|
|
|
|
elem->cell.seq_lmbs = cpu_to_be32(seq_lmbs);
|
|
|
|
elem->cell.base_addr = cpu_to_be64(base_addr);
|
|
|
|
elem->cell.drc_index = cpu_to_be32(drc_index);
|
|
|
|
elem->cell.aa_index = cpu_to_be32(aa_index);
|
|
|
|
elem->cell.flags = cpu_to_be32(flags);
|
|
|
|
|
|
|
|
return elem;
|
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static int spapr_dt_dynamic_memory_v2(SpaprMachineState *spapr, void *fdt,
|
|
|
|
int offset, MemoryDeviceInfoList *dimms)
|
2018-04-19 09:47:35 +03:00
|
|
|
{
|
2018-04-23 19:51:17 +03:00
|
|
|
MachineState *machine = MACHINE(spapr);
|
2019-02-13 20:29:26 +03:00
|
|
|
uint8_t *int_buf, *cur_index;
|
2018-04-19 09:47:35 +03:00
|
|
|
int ret;
|
|
|
|
uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
uint64_t addr, cur_addr, size;
|
2018-04-23 19:51:17 +03:00
|
|
|
uint32_t nr_boot_lmbs = (machine->device_memory->base / lmb_size);
|
|
|
|
uint64_t mem_end = machine->device_memory->base +
|
|
|
|
memory_region_size(&machine->device_memory->mr);
|
2019-02-13 20:29:26 +03:00
|
|
|
uint32_t node, buf_len, nr_entries = 0;
|
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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2018-04-19 09:47:35 +03:00
|
|
|
DrconfCellQueue *elem, *next;
|
|
|
|
MemoryDeviceInfoList *info;
|
|
|
|
QSIMPLEQ_HEAD(, DrconfCellQueue) drconf_queue
|
|
|
|
= QSIMPLEQ_HEAD_INITIALIZER(drconf_queue);
|
|
|
|
|
|
|
|
/* Entry to cover RAM and the gap area */
|
|
|
|
elem = spapr_get_drconf_cell(nr_boot_lmbs, 0, 0, -1,
|
|
|
|
SPAPR_LMB_FLAGS_RESERVED |
|
|
|
|
SPAPR_LMB_FLAGS_DRC_INVALID);
|
|
|
|
QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
|
|
|
|
nr_entries++;
|
|
|
|
|
2018-04-23 19:51:17 +03:00
|
|
|
cur_addr = machine->device_memory->base;
|
2018-04-19 09:47:35 +03:00
|
|
|
for (info = dimms; info; info = info->next) {
|
|
|
|
PCDIMMDeviceInfo *di = info->value->u.dimm.data;
|
|
|
|
|
|
|
|
addr = di->addr;
|
|
|
|
size = di->size;
|
|
|
|
node = di->node;
|
|
|
|
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
/*
|
|
|
|
* The NVDIMM area is hotpluggable after the NVDIMM is unplugged. The
|
|
|
|
* area is marked hotpluggable in the next iteration for the bigger
|
|
|
|
* chunk including the NVDIMM occupied area.
|
|
|
|
*/
|
|
|
|
if (info->value->type == MEMORY_DEVICE_INFO_KIND_NVDIMM)
|
|
|
|
continue;
|
|
|
|
|
2018-04-19 09:47:35 +03:00
|
|
|
/* Entry for hot-pluggable area */
|
|
|
|
if (cur_addr < addr) {
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, cur_addr / lmb_size);
|
|
|
|
g_assert(drc);
|
|
|
|
elem = spapr_get_drconf_cell((addr - cur_addr) / lmb_size,
|
|
|
|
cur_addr, spapr_drc_index(drc), -1, 0);
|
|
|
|
QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
|
|
|
|
nr_entries++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Entry for DIMM */
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, addr / lmb_size);
|
|
|
|
g_assert(drc);
|
|
|
|
elem = spapr_get_drconf_cell(size / lmb_size, addr,
|
|
|
|
spapr_drc_index(drc), node,
|
2020-05-11 23:02:02 +03:00
|
|
|
(SPAPR_LMB_FLAGS_ASSIGNED |
|
|
|
|
SPAPR_LMB_FLAGS_HOTREMOVABLE));
|
2018-04-19 09:47:35 +03:00
|
|
|
QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
|
|
|
|
nr_entries++;
|
|
|
|
cur_addr = addr + size;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Entry for remaining hotpluggable area */
|
|
|
|
if (cur_addr < mem_end) {
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, cur_addr / lmb_size);
|
|
|
|
g_assert(drc);
|
|
|
|
elem = spapr_get_drconf_cell((mem_end - cur_addr) / lmb_size,
|
|
|
|
cur_addr, spapr_drc_index(drc), -1, 0);
|
|
|
|
QSIMPLEQ_INSERT_TAIL(&drconf_queue, elem, entry);
|
|
|
|
nr_entries++;
|
|
|
|
}
|
|
|
|
|
|
|
|
buf_len = nr_entries * sizeof(struct sPAPRDrconfCellV2) + sizeof(uint32_t);
|
|
|
|
int_buf = cur_index = g_malloc0(buf_len);
|
|
|
|
*(uint32_t *)int_buf = cpu_to_be32(nr_entries);
|
|
|
|
cur_index += sizeof(nr_entries);
|
|
|
|
|
|
|
|
QSIMPLEQ_FOREACH_SAFE(elem, &drconf_queue, entry, next) {
|
|
|
|
memcpy(cur_index, &elem->cell, sizeof(elem->cell));
|
|
|
|
cur_index += sizeof(elem->cell);
|
|
|
|
QSIMPLEQ_REMOVE(&drconf_queue, elem, DrconfCellQueue, entry);
|
|
|
|
g_free(elem);
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = fdt_setprop(fdt, offset, "ibm,dynamic-memory-v2", int_buf, buf_len);
|
|
|
|
g_free(int_buf);
|
|
|
|
if (ret < 0) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static int spapr_dt_dynamic_memory(SpaprMachineState *spapr, void *fdt,
|
2018-04-19 09:47:35 +03:00
|
|
|
int offset, MemoryDeviceInfoList *dimms)
|
|
|
|
{
|
2018-04-23 19:51:17 +03:00
|
|
|
MachineState *machine = MACHINE(spapr);
|
2018-04-19 09:47:35 +03:00
|
|
|
int i, ret;
|
2015-07-13 03:34:00 +03:00
|
|
|
uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
|
2018-04-23 19:51:25 +03:00
|
|
|
uint32_t device_lmb_start = machine->device_memory->base / lmb_size;
|
2018-04-23 19:51:17 +03:00
|
|
|
uint32_t nr_lmbs = (machine->device_memory->base +
|
|
|
|
memory_region_size(&machine->device_memory->mr)) /
|
2016-06-10 08:14:48 +03:00
|
|
|
lmb_size;
|
2015-07-13 03:34:00 +03:00
|
|
|
uint32_t *int_buf, *cur_index, buf_len;
|
2016-01-19 07:39:21 +03:00
|
|
|
|
2015-09-15 22:34:20 +03:00
|
|
|
/*
|
|
|
|
* Allocate enough buffer size to fit in ibm,dynamic-memory
|
|
|
|
*/
|
2018-04-19 09:47:35 +03:00
|
|
|
buf_len = (nr_lmbs * SPAPR_DR_LMB_LIST_ENTRY_SIZE + 1) * sizeof(uint32_t);
|
2015-07-13 03:34:00 +03:00
|
|
|
cur_index = int_buf = g_malloc0(buf_len);
|
|
|
|
int_buf[0] = cpu_to_be32(nr_lmbs);
|
|
|
|
cur_index++;
|
|
|
|
for (i = 0; i < nr_lmbs; i++) {
|
2016-06-10 08:14:48 +03:00
|
|
|
uint64_t addr = i * lmb_size;
|
2015-07-13 03:34:00 +03:00
|
|
|
uint32_t *dynamic_memory = cur_index;
|
|
|
|
|
2018-04-23 19:51:25 +03:00
|
|
|
if (i >= device_lmb_start) {
|
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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2016-06-10 08:14:48 +03:00
|
|
|
|
2017-06-04 13:26:03 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB, i);
|
2016-06-10 08:14:48 +03:00
|
|
|
g_assert(drc);
|
|
|
|
|
|
|
|
dynamic_memory[0] = cpu_to_be32(addr >> 32);
|
|
|
|
dynamic_memory[1] = cpu_to_be32(addr & 0xffffffff);
|
2017-06-02 06:49:20 +03:00
|
|
|
dynamic_memory[2] = cpu_to_be32(spapr_drc_index(drc));
|
2016-06-10 08:14:48 +03:00
|
|
|
dynamic_memory[3] = cpu_to_be32(0); /* reserved */
|
2017-12-05 18:41:17 +03:00
|
|
|
dynamic_memory[4] = cpu_to_be32(spapr_pc_dimm_node(dimms, addr));
|
2016-06-10 08:14:48 +03:00
|
|
|
if (memory_region_present(get_system_memory(), addr)) {
|
|
|
|
dynamic_memory[5] = cpu_to_be32(SPAPR_LMB_FLAGS_ASSIGNED);
|
|
|
|
} else {
|
|
|
|
dynamic_memory[5] = cpu_to_be32(0);
|
|
|
|
}
|
2015-07-13 03:34:00 +03:00
|
|
|
} else {
|
2016-06-10 08:14:48 +03:00
|
|
|
/*
|
|
|
|
* LMB information for RMA, boot time RAM and gap b/n RAM and
|
2018-04-23 19:51:25 +03:00
|
|
|
* device memory region -- all these are marked as reserved
|
2016-06-10 08:14:48 +03:00
|
|
|
* and as having no valid DRC.
|
|
|
|
*/
|
|
|
|
dynamic_memory[0] = cpu_to_be32(addr >> 32);
|
|
|
|
dynamic_memory[1] = cpu_to_be32(addr & 0xffffffff);
|
|
|
|
dynamic_memory[2] = cpu_to_be32(0);
|
|
|
|
dynamic_memory[3] = cpu_to_be32(0); /* reserved */
|
|
|
|
dynamic_memory[4] = cpu_to_be32(-1);
|
|
|
|
dynamic_memory[5] = cpu_to_be32(SPAPR_LMB_FLAGS_RESERVED |
|
|
|
|
SPAPR_LMB_FLAGS_DRC_INVALID);
|
2015-07-13 03:34:00 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
cur_index += SPAPR_DR_LMB_LIST_ENTRY_SIZE;
|
|
|
|
}
|
|
|
|
ret = fdt_setprop(fdt, offset, "ibm,dynamic-memory", int_buf, buf_len);
|
2018-04-19 09:47:35 +03:00
|
|
|
g_free(int_buf);
|
2015-07-13 03:34:00 +03:00
|
|
|
if (ret < 0) {
|
2018-04-19 09:47:35 +03:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adds ibm,dynamic-reconfiguration-memory node.
|
|
|
|
* Refer to docs/specs/ppc-spapr-hotplug.txt for the documentation
|
|
|
|
* of this device tree node.
|
|
|
|
*/
|
2020-01-22 08:15:43 +03:00
|
|
|
static int spapr_dt_dynamic_reconfiguration_memory(SpaprMachineState *spapr,
|
|
|
|
void *fdt)
|
2018-04-19 09:47:35 +03:00
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
2020-09-04 01:06:35 +03:00
|
|
|
int ret, offset;
|
2018-04-19 09:47:35 +03:00
|
|
|
uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
|
2020-07-15 03:42:28 +03:00
|
|
|
uint32_t prop_lmb_size[] = {cpu_to_be32(lmb_size >> 32),
|
|
|
|
cpu_to_be32(lmb_size & 0xffffffff)};
|
2018-04-19 09:47:35 +03:00
|
|
|
MemoryDeviceInfoList *dimms = NULL;
|
|
|
|
|
2023-06-23 15:45:47 +03:00
|
|
|
/* Don't create the node if there is no device memory. */
|
|
|
|
if (!machine->device_memory) {
|
2018-04-19 09:47:35 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
offset = fdt_add_subnode(fdt, 0, "ibm,dynamic-reconfiguration-memory");
|
|
|
|
|
|
|
|
ret = fdt_setprop(fdt, offset, "ibm,lmb-size", prop_lmb_size,
|
|
|
|
sizeof(prop_lmb_size));
|
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = fdt_setprop_cell(fdt, offset, "ibm,memory-flags-mask", 0xff);
|
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = fdt_setprop_cell(fdt, offset, "ibm,memory-preservation-time", 0x0);
|
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ibm,dynamic-memory or ibm,dynamic-memory-v2 */
|
2018-04-23 19:51:16 +03:00
|
|
|
dimms = qmp_memory_device_list();
|
2018-04-19 09:47:35 +03:00
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_DRMEM_V2)) {
|
2020-01-22 08:15:43 +03:00
|
|
|
ret = spapr_dt_dynamic_memory_v2(spapr, fdt, offset, dimms);
|
2018-04-19 09:47:35 +03:00
|
|
|
} else {
|
2020-01-22 08:15:43 +03:00
|
|
|
ret = spapr_dt_dynamic_memory(spapr, fdt, offset, dimms);
|
2018-04-19 09:47:35 +03:00
|
|
|
}
|
|
|
|
qapi_free_MemoryDeviceInfoList(dimms);
|
|
|
|
|
|
|
|
if (ret < 0) {
|
|
|
|
return ret;
|
2015-07-13 03:34:00 +03:00
|
|
|
}
|
|
|
|
|
2020-09-04 01:06:35 +03:00
|
|
|
ret = spapr_numa_write_assoc_lookup_arrays(spapr, fdt, offset);
|
2018-04-19 09:47:35 +03:00
|
|
|
|
2015-07-13 03:34:00 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static int spapr_dt_memory(SpaprMachineState *spapr, void *fdt)
|
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 07:47:29 +03:00
|
|
|
{
|
2020-01-22 07:46:35 +03:00
|
|
|
MachineState *machine = MACHINE(spapr);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
2020-01-22 07:46:35 +03:00
|
|
|
hwaddr mem_start, node_size;
|
|
|
|
int i, nb_nodes = machine->numa_state->num_nodes;
|
|
|
|
NodeInfo *nodes = machine->numa_state->nodes;
|
|
|
|
|
|
|
|
for (i = 0, mem_start = 0; i < nb_nodes; ++i) {
|
|
|
|
if (!nodes[i].node_mem) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (mem_start >= machine->ram_size) {
|
|
|
|
node_size = 0;
|
|
|
|
} else {
|
|
|
|
node_size = nodes[i].node_mem;
|
|
|
|
if (node_size > machine->ram_size - mem_start) {
|
|
|
|
node_size = machine->ram_size - mem_start;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!mem_start) {
|
|
|
|
/* spapr_machine_init() checks for rma_size <= node0_size
|
|
|
|
* already */
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
spapr_dt_memory_node(spapr, fdt, i, 0, spapr->rma_size);
|
2020-01-22 07:46:35 +03:00
|
|
|
mem_start += spapr->rma_size;
|
|
|
|
node_size -= spapr->rma_size;
|
|
|
|
}
|
|
|
|
for ( ; node_size; ) {
|
|
|
|
hwaddr sizetmp = pow2floor(node_size);
|
|
|
|
|
|
|
|
/* mem_start != 0 here */
|
|
|
|
if (ctzl(mem_start) < ctzl(sizetmp)) {
|
|
|
|
sizetmp = 1ULL << ctzl(mem_start);
|
|
|
|
}
|
|
|
|
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
spapr_dt_memory_node(spapr, fdt, i, mem_start, sizetmp);
|
2020-01-22 07:46:35 +03:00
|
|
|
node_size -= sizetmp;
|
|
|
|
mem_start += sizetmp;
|
|
|
|
}
|
|
|
|
}
|
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 07:47:29 +03:00
|
|
|
|
|
|
|
/* Generate ibm,dynamic-reconfiguration-memory node if required */
|
2020-01-22 07:46:35 +03:00
|
|
|
if (spapr_ovec_test(spapr->ov5_cas, OV5_DRCONF_MEMORY)) {
|
|
|
|
int ret;
|
|
|
|
|
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 07:47:29 +03:00
|
|
|
g_assert(smc->dr_lmb_enabled);
|
2020-01-22 08:15:43 +03:00
|
|
|
ret = spapr_dt_dynamic_reconfiguration_memory(spapr, fdt);
|
2016-10-25 07:47:30 +03:00
|
|
|
if (ret) {
|
2020-01-06 21:23:27 +03:00
|
|
|
return ret;
|
2016-10-25 07:47:30 +03: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 07:47:29 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static void spapr_dt_cpu(CPUState *cs, void *fdt, int offset,
|
|
|
|
SpaprMachineState *spapr)
|
2020-01-22 07:46:35 +03:00
|
|
|
{
|
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cs);
|
|
|
|
int index = spapr_get_vcpu_id(cpu);
|
|
|
|
uint32_t segs[] = {cpu_to_be32(28), cpu_to_be32(40),
|
|
|
|
0xffffffff, 0xffffffff};
|
|
|
|
uint32_t tbfreq = kvm_enabled() ? kvmppc_get_tbfreq()
|
|
|
|
: SPAPR_TIMEBASE_FREQ;
|
|
|
|
uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq() : 1000000000;
|
|
|
|
uint32_t page_sizes_prop[64];
|
|
|
|
size_t page_sizes_prop_size;
|
|
|
|
unsigned int smp_threads = ms->smp.threads;
|
|
|
|
uint32_t vcpus_per_socket = smp_threads * ms->smp.cores;
|
|
|
|
uint32_t pft_size_prop[] = {0, cpu_to_be32(spapr->htab_shift)};
|
|
|
|
int compat_smt = MIN(smp_threads, ppc_compat_max_vthreads(cpu));
|
|
|
|
SpaprDrc *drc;
|
|
|
|
int drc_index;
|
|
|
|
uint32_t radix_AP_encodings[PPC_PAGE_SIZES_MAX_SZ];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_CPU, index);
|
|
|
|
if (drc) {
|
|
|
|
drc_index = spapr_drc_index(drc);
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,my-drc-index", drc_index)));
|
|
|
|
}
|
|
|
|
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "reg", index)));
|
|
|
|
_FDT((fdt_setprop_string(fdt, offset, "device_type", "cpu")));
|
|
|
|
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "cpu-version", env->spr[SPR_PVR])));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "d-cache-block-size",
|
|
|
|
env->dcache_line_size)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "d-cache-line-size",
|
|
|
|
env->dcache_line_size)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "i-cache-block-size",
|
|
|
|
env->icache_line_size)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "i-cache-line-size",
|
|
|
|
env->icache_line_size)));
|
|
|
|
|
|
|
|
if (pcc->l1_dcache_size) {
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "d-cache-size",
|
|
|
|
pcc->l1_dcache_size)));
|
|
|
|
} else {
|
|
|
|
warn_report("Unknown L1 dcache size for cpu");
|
|
|
|
}
|
|
|
|
if (pcc->l1_icache_size) {
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "i-cache-size",
|
|
|
|
pcc->l1_icache_size)));
|
|
|
|
} else {
|
|
|
|
warn_report("Unknown L1 icache size for cpu");
|
|
|
|
}
|
|
|
|
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "timebase-frequency", tbfreq)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "clock-frequency", cpufreq)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "slb-size", cpu->hash64_opts->slb_size)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,slb-size", cpu->hash64_opts->slb_size)));
|
|
|
|
_FDT((fdt_setprop_string(fdt, offset, "status", "okay")));
|
|
|
|
_FDT((fdt_setprop(fdt, offset, "64-bit", NULL, 0)));
|
|
|
|
|
2021-05-07 19:41:46 +03:00
|
|
|
if (ppc_has_spr(cpu, SPR_PURR)) {
|
2020-01-22 07:46:35 +03:00
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,purr", 1)));
|
|
|
|
}
|
2021-05-07 19:41:46 +03:00
|
|
|
if (ppc_has_spr(cpu, SPR_PURR)) {
|
2020-01-22 07:46:35 +03:00
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,spurr", 1)));
|
|
|
|
}
|
2018-04-19 09:47:35 +03:00
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
if (ppc_hash64_has(cpu, PPC_HASH64_1TSEG)) {
|
|
|
|
_FDT((fdt_setprop(fdt, offset, "ibm,processor-segment-sizes",
|
|
|
|
segs, sizeof(segs))));
|
2018-04-19 09:47:35 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
/* Advertise VSX (vector extensions) if available
|
|
|
|
* 1 == VMX / Altivec available
|
|
|
|
* 2 == VSX available
|
|
|
|
*
|
|
|
|
* Only CPUs for which we create core types in spapr_cpu_core.c
|
|
|
|
* are possible, and all of those have VMX */
|
2022-01-12 13:28:26 +03:00
|
|
|
if (env->insns_flags & PPC_ALTIVEC) {
|
|
|
|
if (spapr_get_cap(spapr, SPAPR_CAP_VSX) != 0) {
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 2)));
|
|
|
|
} else {
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 1)));
|
|
|
|
}
|
2020-01-22 07:46:35 +03:00
|
|
|
}
|
2018-04-19 09:47:35 +03:00
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
/* Advertise DFP (Decimal Floating Point) if available
|
|
|
|
* 0 / no property == no DFP
|
|
|
|
* 1 == DFP available */
|
|
|
|
if (spapr_get_cap(spapr, SPAPR_CAP_DFP) != 0) {
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,dfp", 1)));
|
2018-04-19 09:47:35 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
page_sizes_prop_size = ppc_create_page_sizes_prop(cpu, page_sizes_prop,
|
|
|
|
sizeof(page_sizes_prop));
|
|
|
|
if (page_sizes_prop_size) {
|
|
|
|
_FDT((fdt_setprop(fdt, offset, "ibm,segment-page-sizes",
|
|
|
|
page_sizes_prop, page_sizes_prop_size)));
|
2018-04-19 09:47:35 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
spapr_dt_pa_features(spapr, cpu, fdt, offset);
|
2020-01-22 07:46:35 +03:00
|
|
|
|
|
|
|
_FDT((fdt_setprop_cell(fdt, offset, "ibm,chip-id",
|
|
|
|
cs->cpu_index / vcpus_per_socket)));
|
|
|
|
|
|
|
|
_FDT((fdt_setprop(fdt, offset, "ibm,pft-size",
|
|
|
|
pft_size_prop, sizeof(pft_size_prop))));
|
|
|
|
|
|
|
|
if (ms->numa_state->num_nodes > 1) {
|
2020-09-04 01:06:34 +03:00
|
|
|
_FDT(spapr_numa_fixup_cpu_dt(spapr, fdt, offset, cpu));
|
2018-04-19 09:47:35 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
_FDT(spapr_fixup_cpu_smt_dt(fdt, offset, cpu, compat_smt));
|
|
|
|
|
|
|
|
if (pcc->radix_page_info) {
|
|
|
|
for (i = 0; i < pcc->radix_page_info->count; i++) {
|
|
|
|
radix_AP_encodings[i] =
|
|
|
|
cpu_to_be32(pcc->radix_page_info->entries[i]);
|
|
|
|
}
|
|
|
|
_FDT((fdt_setprop(fdt, offset, "ibm,processor-radix-AP-encodings",
|
|
|
|
radix_AP_encodings,
|
|
|
|
pcc->radix_page_info->count *
|
|
|
|
sizeof(radix_AP_encodings[0]))));
|
2018-04-19 09:47:35 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
/*
|
|
|
|
* We set this property to let the guest know that it can use the large
|
|
|
|
* decrementer and its width in bits.
|
|
|
|
*/
|
|
|
|
if (spapr_get_cap(spapr, SPAPR_CAP_LARGE_DECREMENTER) != SPAPR_CAP_OFF)
|
|
|
|
_FDT((fdt_setprop_u32(fdt, offset, "ibm,dec-bits",
|
|
|
|
pcc->lrg_decr_bits)));
|
|
|
|
}
|
|
|
|
|
2023-09-18 17:58:45 +03:00
|
|
|
static void spapr_dt_one_cpu(void *fdt, SpaprMachineState *spapr, CPUState *cs,
|
|
|
|
int cpus_offset)
|
|
|
|
{
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
int index = spapr_get_vcpu_id(cpu);
|
|
|
|
DeviceClass *dc = DEVICE_GET_CLASS(cs);
|
|
|
|
g_autofree char *nodename = NULL;
|
|
|
|
int offset;
|
|
|
|
|
|
|
|
if (!spapr_is_thread0_in_vcore(spapr, cpu)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
nodename = g_strdup_printf("%s@%x", dc->fw_name, index);
|
|
|
|
offset = fdt_add_subnode(fdt, cpus_offset, nodename);
|
|
|
|
_FDT(offset);
|
|
|
|
spapr_dt_cpu(cs, fdt, offset, spapr);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static void spapr_dt_cpus(void *fdt, SpaprMachineState *spapr)
|
2020-01-22 07:46:35 +03:00
|
|
|
{
|
|
|
|
CPUState **rev;
|
|
|
|
CPUState *cs;
|
|
|
|
int n_cpus;
|
|
|
|
int cpus_offset;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
cpus_offset = fdt_add_subnode(fdt, 0, "cpus");
|
|
|
|
_FDT(cpus_offset);
|
|
|
|
_FDT((fdt_setprop_cell(fdt, cpus_offset, "#address-cells", 0x1)));
|
|
|
|
_FDT((fdt_setprop_cell(fdt, cpus_offset, "#size-cells", 0x0)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We walk the CPUs in reverse order to ensure that CPU DT nodes
|
|
|
|
* created by fdt_add_subnode() end up in the right order in FDT
|
|
|
|
* for the guest kernel the enumerate the CPUs correctly.
|
|
|
|
*
|
|
|
|
* The CPU list cannot be traversed in reverse order, so we need
|
|
|
|
* to do extra work.
|
|
|
|
*/
|
|
|
|
n_cpus = 0;
|
|
|
|
rev = NULL;
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
rev = g_renew(CPUState *, rev, n_cpus + 1);
|
|
|
|
rev[n_cpus++] = cs;
|
2015-07-13 03:34:00 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
for (i = n_cpus - 1; i >= 0; i--) {
|
2023-09-18 17:58:45 +03:00
|
|
|
spapr_dt_one_cpu(fdt, spapr, rev[i], cpus_offset);
|
2015-07-13 03:34:00 +03:00
|
|
|
}
|
2018-04-19 09:47:35 +03:00
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
g_free(rev);
|
2015-07-13 03:34:00 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
static int spapr_dt_rng(void *fdt)
|
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 07:47:29 +03:00
|
|
|
{
|
2020-01-22 07:46:35 +03:00
|
|
|
int node;
|
|
|
|
int ret;
|
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 07:47:29 +03:00
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
node = qemu_fdt_add_subnode(fdt, "/ibm,platform-facilities");
|
|
|
|
if (node <= 0) {
|
|
|
|
return -1;
|
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 07:47:29 +03:00
|
|
|
}
|
2020-01-22 07:46:35 +03:00
|
|
|
ret = fdt_setprop_string(fdt, node, "device_type",
|
|
|
|
"ibm,platform-facilities");
|
|
|
|
ret |= fdt_setprop_cell(fdt, node, "#address-cells", 0x1);
|
|
|
|
ret |= fdt_setprop_cell(fdt, node, "#size-cells", 0x0);
|
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 07:47:29 +03:00
|
|
|
|
2020-01-22 07:46:35 +03:00
|
|
|
node = fdt_add_subnode(fdt, node, "ibm,random-v1");
|
|
|
|
if (node <= 0) {
|
|
|
|
return -1;
|
2016-10-25 07:47:30 +03:00
|
|
|
}
|
2020-01-22 07:46:35 +03:00
|
|
|
ret |= fdt_setprop_string(fdt, node, "compatible", "ibm,random");
|
|
|
|
|
|
|
|
return ret ? -1 : 0;
|
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 07:47:29 +03: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 07:35:37 +03:00
|
|
|
static void spapr_dt_rtas(SpaprMachineState *spapr, void *fdt)
|
2016-10-20 07:55:36 +03:00
|
|
|
{
|
2019-05-18 23:54:22 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
2016-10-20 07:55:36 +03:00
|
|
|
int rtas;
|
|
|
|
GString *hypertas = g_string_sized_new(256);
|
|
|
|
GString *qemu_hypertas = g_string_sized_new(256);
|
|
|
|
uint32_t lrdr_capacity[] = {
|
2023-06-23 15:45:47 +03:00
|
|
|
0,
|
|
|
|
0,
|
2020-07-15 03:42:28 +03:00
|
|
|
cpu_to_be32(SPAPR_MEMORY_BLOCK_SIZE >> 32),
|
|
|
|
cpu_to_be32(SPAPR_MEMORY_BLOCK_SIZE & 0xffffffff),
|
2019-05-18 23:54:22 +03:00
|
|
|
cpu_to_be32(ms->smp.max_cpus / ms->smp.threads),
|
2016-10-20 07:55:36 +03:00
|
|
|
};
|
|
|
|
|
2023-06-23 15:45:47 +03:00
|
|
|
/* Do we have device memory? */
|
|
|
|
if (MACHINE(spapr)->device_memory) {
|
|
|
|
uint64_t max_device_addr = MACHINE(spapr)->device_memory->base +
|
|
|
|
memory_region_size(&MACHINE(spapr)->device_memory->mr);
|
|
|
|
|
|
|
|
lrdr_capacity[0] = cpu_to_be32(max_device_addr >> 32);
|
|
|
|
lrdr_capacity[1] = cpu_to_be32(max_device_addr & 0xffffffff);
|
|
|
|
}
|
|
|
|
|
2016-10-20 07:55:36 +03:00
|
|
|
_FDT(rtas = fdt_add_subnode(fdt, 0, "rtas"));
|
|
|
|
|
|
|
|
/* hypertas */
|
|
|
|
add_str(hypertas, "hcall-pft");
|
|
|
|
add_str(hypertas, "hcall-term");
|
|
|
|
add_str(hypertas, "hcall-dabr");
|
|
|
|
add_str(hypertas, "hcall-interrupt");
|
|
|
|
add_str(hypertas, "hcall-tce");
|
|
|
|
add_str(hypertas, "hcall-vio");
|
|
|
|
add_str(hypertas, "hcall-splpar");
|
2019-07-18 06:42:14 +03:00
|
|
|
add_str(hypertas, "hcall-join");
|
2016-10-20 07:55:36 +03:00
|
|
|
add_str(hypertas, "hcall-bulk");
|
|
|
|
add_str(hypertas, "hcall-set-mode");
|
|
|
|
add_str(hypertas, "hcall-sprg0");
|
|
|
|
add_str(hypertas, "hcall-copy");
|
|
|
|
add_str(hypertas, "hcall-debug");
|
2018-12-19 19:35:41 +03:00
|
|
|
add_str(hypertas, "hcall-vphn");
|
2021-07-06 14:24:40 +03:00
|
|
|
if (spapr_get_cap(spapr, SPAPR_CAP_RPT_INVALIDATE) == SPAPR_CAP_ON) {
|
|
|
|
add_str(hypertas, "hcall-rpt-invalidate");
|
|
|
|
}
|
|
|
|
|
2016-10-20 07:55:36 +03:00
|
|
|
add_str(qemu_hypertas, "hcall-memop1");
|
|
|
|
|
|
|
|
if (!kvm_enabled() || kvmppc_spapr_use_multitce()) {
|
|
|
|
add_str(hypertas, "hcall-multi-tce");
|
|
|
|
}
|
2017-05-12 08:46:11 +03:00
|
|
|
|
|
|
|
if (spapr->resize_hpt != SPAPR_RESIZE_HPT_DISABLED) {
|
|
|
|
add_str(hypertas, "hcall-hpt-resize");
|
|
|
|
}
|
|
|
|
|
2022-06-22 08:10:08 +03:00
|
|
|
add_str(hypertas, "hcall-watchdog");
|
|
|
|
|
2016-10-20 07:55:36 +03:00
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,hypertas-functions",
|
|
|
|
hypertas->str, hypertas->len));
|
|
|
|
g_string_free(hypertas, TRUE);
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "qemu,hypertas-functions",
|
|
|
|
qemu_hypertas->str, qemu_hypertas->len));
|
|
|
|
g_string_free(qemu_hypertas, TRUE);
|
|
|
|
|
2020-09-01 15:56:39 +03:00
|
|
|
spapr_numa_write_rtas_dt(spapr, fdt, rtas);
|
2018-04-11 21:41:59 +03:00
|
|
|
|
2020-03-16 17:26:12 +03:00
|
|
|
/*
|
|
|
|
* FWNMI reserves RTAS_ERROR_LOG_MAX for the machine check error log,
|
|
|
|
* and 16 bytes per CPU for system reset error log plus an extra 8 bytes.
|
|
|
|
*
|
|
|
|
* The system reset requirements are driven by existing Linux and PowerVM
|
|
|
|
* implementation which (contrary to PAPR) saves r3 in the error log
|
|
|
|
* structure like machine check, so Linux expects to find the saved r3
|
|
|
|
* value at the address in r3 upon FWNMI-enabled sreset interrupt (and
|
|
|
|
* does not look at the error value).
|
|
|
|
*
|
|
|
|
* System reset interrupts are not subject to interlock like machine
|
|
|
|
* check, so this memory area could be corrupted if the sreset is
|
|
|
|
* interrupted by a machine check (or vice versa) if it was shared. To
|
|
|
|
* prevent this, system reset uses per-CPU areas for the sreset save
|
|
|
|
* area. A system reset that interrupts a system reset handler could
|
|
|
|
* still overwrite this area, but Linux doesn't try to recover in that
|
|
|
|
* case anyway.
|
|
|
|
*
|
|
|
|
* The extra 8 bytes is required because Linux's FWNMI error log check
|
|
|
|
* is off-by-one.
|
2021-06-22 10:03:36 +03:00
|
|
|
*
|
|
|
|
* RTAS_MIN_SIZE is required for the RTAS blob itself.
|
2020-03-16 17:26:12 +03:00
|
|
|
*/
|
2021-06-22 10:03:36 +03:00
|
|
|
_FDT(fdt_setprop_cell(fdt, rtas, "rtas-size", RTAS_MIN_SIZE +
|
|
|
|
RTAS_ERROR_LOG_MAX +
|
|
|
|
ms->smp.max_cpus * sizeof(uint64_t) * 2 +
|
|
|
|
sizeof(uint64_t)));
|
2016-10-20 07:55:36 +03:00
|
|
|
_FDT(fdt_setprop_cell(fdt, rtas, "rtas-error-log-max",
|
|
|
|
RTAS_ERROR_LOG_MAX));
|
|
|
|
_FDT(fdt_setprop_cell(fdt, rtas, "rtas-event-scan-rate",
|
|
|
|
RTAS_EVENT_SCAN_RATE));
|
|
|
|
|
2017-12-08 06:11:49 +03:00
|
|
|
g_assert(msi_nonbroken);
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,change-msix-capable", NULL, 0));
|
2016-10-20 07:55:36 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* According to PAPR, rtas ibm,os-term does not guarantee a return
|
|
|
|
* back to the guest cpu.
|
|
|
|
*
|
|
|
|
* While an additional ibm,extended-os-term property indicates
|
|
|
|
* that rtas call return will always occur. Set this property.
|
|
|
|
*/
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,extended-os-term", NULL, 0));
|
|
|
|
|
|
|
|
_FDT(fdt_setprop(fdt, rtas, "ibm,lrdr-capacity",
|
|
|
|
lrdr_capacity, sizeof(lrdr_capacity)));
|
|
|
|
|
|
|
|
spapr_dt_rtas_tokens(fdt, rtas);
|
|
|
|
}
|
|
|
|
|
2018-12-18 01:34:42 +03:00
|
|
|
/*
|
|
|
|
* Prepare ibm,arch-vec-5-platform-support, which indicates the MMU
|
|
|
|
* and the XIVE features that the guest may request and thus the valid
|
|
|
|
* values for bytes 23..26 of option vector 5:
|
|
|
|
*/
|
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 07:35:37 +03:00
|
|
|
static void spapr_dt_ov5_platform_support(SpaprMachineState *spapr, void *fdt,
|
2018-12-18 01:34:42 +03:00
|
|
|
int chosen)
|
2017-03-23 06:46:00 +03:00
|
|
|
{
|
2017-05-02 09:37:18 +03:00
|
|
|
PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
|
|
|
|
|
2017-07-05 20:13:14 +03:00
|
|
|
char val[2 * 4] = {
|
2019-09-25 08:12:07 +03:00
|
|
|
23, 0x00, /* XICS / XIVE mode */
|
2017-03-23 06:46:00 +03:00
|
|
|
24, 0x00, /* Hash/Radix, filled in below. */
|
|
|
|
25, 0x00, /* Hash options: Segment Tables == no, GTSE == no. */
|
|
|
|
26, 0x40, /* Radix options: GTSE == yes. */
|
|
|
|
};
|
|
|
|
|
2019-09-25 08:12:07 +03:00
|
|
|
if (spapr->irq->xics && spapr->irq->xive) {
|
|
|
|
val[1] = SPAPR_OV5_XIVE_BOTH;
|
|
|
|
} else if (spapr->irq->xive) {
|
|
|
|
val[1] = SPAPR_OV5_XIVE_EXPLOIT;
|
|
|
|
} else {
|
|
|
|
assert(spapr->irq->xics);
|
|
|
|
val[1] = SPAPR_OV5_XIVE_LEGACY;
|
|
|
|
}
|
|
|
|
|
2017-11-17 08:39:00 +03:00
|
|
|
if (!ppc_check_compat(first_ppc_cpu, CPU_POWERPC_LOGICAL_3_00, 0,
|
|
|
|
first_ppc_cpu->compat_pvr)) {
|
2018-12-18 01:34:42 +03:00
|
|
|
/*
|
|
|
|
* If we're in a pre POWER9 compat mode then the guest should
|
|
|
|
* do hash and use the legacy interrupt mode
|
|
|
|
*/
|
2019-09-25 08:12:07 +03:00
|
|
|
val[1] = SPAPR_OV5_XIVE_LEGACY; /* XICS */
|
2017-11-17 08:39:00 +03:00
|
|
|
val[3] = 0x00; /* Hash */
|
2021-05-05 03:11:30 +03:00
|
|
|
spapr_check_mmu_mode(false);
|
2017-11-17 08:39:00 +03:00
|
|
|
} else if (kvm_enabled()) {
|
2017-03-23 06:46:00 +03:00
|
|
|
if (kvmppc_has_cap_mmu_radix() && kvmppc_has_cap_mmu_hash_v3()) {
|
2017-07-05 20:13:14 +03:00
|
|
|
val[3] = 0x80; /* OV5_MMU_BOTH */
|
2017-03-23 06:46:00 +03:00
|
|
|
} else if (kvmppc_has_cap_mmu_radix()) {
|
2017-07-05 20:13:14 +03:00
|
|
|
val[3] = 0x40; /* OV5_MMU_RADIX_300 */
|
2017-03-23 06:46:00 +03:00
|
|
|
} else {
|
2017-07-05 20:13:14 +03:00
|
|
|
val[3] = 0x00; /* Hash */
|
2017-03-23 06:46:00 +03:00
|
|
|
}
|
|
|
|
} else {
|
2017-11-17 08:39:00 +03:00
|
|
|
/* V3 MMU supports both hash and radix in tcg (with dynamic switching) */
|
|
|
|
val[3] = 0xC0;
|
2017-03-23 06:46:00 +03:00
|
|
|
}
|
|
|
|
_FDT(fdt_setprop(fdt, chosen, "ibm,arch-vec-5-platform-support",
|
|
|
|
val, sizeof(val)));
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
static void spapr_dt_chosen(SpaprMachineState *spapr, void *fdt, bool reset)
|
2016-10-24 04:05:57 +03:00
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
2019-07-19 07:37:34 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
|
2016-10-24 04:05:57 +03:00
|
|
|
int chosen;
|
|
|
|
|
|
|
|
_FDT(chosen = fdt_add_subnode(fdt, 0, "chosen"));
|
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
if (reset) {
|
2021-05-21 19:07:35 +03:00
|
|
|
const char *boot_device = spapr->boot_device;
|
2022-03-02 08:51:39 +03:00
|
|
|
g_autofree char *stdout_path = spapr_vio_stdout_path(spapr->vio_bus);
|
2020-01-22 07:50:42 +03:00
|
|
|
size_t cb = 0;
|
2022-03-02 08:51:39 +03:00
|
|
|
g_autofree char *bootlist = get_boot_devices_list(&cb);
|
2020-01-22 07:50:42 +03:00
|
|
|
|
|
|
|
if (machine->kernel_cmdline && machine->kernel_cmdline[0]) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, chosen, "bootargs",
|
|
|
|
machine->kernel_cmdline));
|
|
|
|
}
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
if (spapr->initrd_size) {
|
|
|
|
_FDT(fdt_setprop_cell(fdt, chosen, "linux,initrd-start",
|
|
|
|
spapr->initrd_base));
|
|
|
|
_FDT(fdt_setprop_cell(fdt, chosen, "linux,initrd-end",
|
|
|
|
spapr->initrd_base + spapr->initrd_size));
|
|
|
|
}
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
if (spapr->kernel_size) {
|
|
|
|
uint64_t kprop[2] = { cpu_to_be64(spapr->kernel_addr),
|
|
|
|
cpu_to_be64(spapr->kernel_size) };
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
_FDT(fdt_setprop(fdt, chosen, "qemu,boot-kernel",
|
2016-10-24 04:05:57 +03:00
|
|
|
&kprop, sizeof(kprop)));
|
2020-01-22 07:50:42 +03:00
|
|
|
if (spapr->kernel_le) {
|
|
|
|
_FDT(fdt_setprop(fdt, chosen, "qemu,boot-kernel-le", NULL, 0));
|
|
|
|
}
|
2016-10-24 04:05:57 +03:00
|
|
|
}
|
2022-04-14 19:52:56 +03:00
|
|
|
if (machine->boot_config.has_menu && machine->boot_config.menu) {
|
|
|
|
_FDT((fdt_setprop_cell(fdt, chosen, "qemu,boot-menu", true)));
|
2020-01-22 07:50:42 +03:00
|
|
|
}
|
|
|
|
_FDT(fdt_setprop_cell(fdt, chosen, "qemu,graphic-width", graphic_width));
|
|
|
|
_FDT(fdt_setprop_cell(fdt, chosen, "qemu,graphic-height", graphic_height));
|
|
|
|
_FDT(fdt_setprop_cell(fdt, chosen, "qemu,graphic-depth", graphic_depth));
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
if (cb && bootlist) {
|
|
|
|
int i;
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
for (i = 0; i < cb; i++) {
|
|
|
|
if (bootlist[i] == '\n') {
|
|
|
|
bootlist[i] = ' ';
|
|
|
|
}
|
2016-10-24 04:05:57 +03:00
|
|
|
}
|
2020-01-22 07:50:42 +03:00
|
|
|
_FDT(fdt_setprop_string(fdt, chosen, "qemu,boot-list", bootlist));
|
2016-10-24 04:05:57 +03:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
if (boot_device && strlen(boot_device)) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, chosen, "qemu,boot-device", boot_device));
|
|
|
|
}
|
|
|
|
|
2022-05-07 08:48:26 +03:00
|
|
|
if (spapr->want_stdout_path && stdout_path) {
|
2020-01-22 07:50:42 +03:00
|
|
|
/*
|
|
|
|
* "linux,stdout-path" and "stdout" properties are
|
|
|
|
* deprecated by linux kernel. New platforms should only
|
|
|
|
* use the "stdout-path" property. Set the new property
|
|
|
|
* and continue using older property to remain compatible
|
|
|
|
* with the existing firmware.
|
|
|
|
*/
|
|
|
|
_FDT(fdt_setprop_string(fdt, chosen, "linux,stdout-path", stdout_path));
|
|
|
|
_FDT(fdt_setprop_string(fdt, chosen, "stdout-path", stdout_path));
|
|
|
|
}
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2018-03-01 09:05:50 +03:00
|
|
|
/*
|
2020-01-22 07:50:42 +03:00
|
|
|
* We can deal with BAR reallocation just fine, advertise it
|
|
|
|
* to the guest
|
2018-03-01 09:05:50 +03:00
|
|
|
*/
|
2020-01-22 07:50:42 +03:00
|
|
|
if (smc->linux_pci_probe) {
|
|
|
|
_FDT(fdt_setprop_cell(fdt, chosen, "linux,pci-probe-only", 0));
|
|
|
|
}
|
2016-10-24 04:05:57 +03:00
|
|
|
|
2020-01-22 07:50:42 +03:00
|
|
|
spapr_dt_ov5_platform_support(spapr, fdt, chosen);
|
|
|
|
}
|
2017-03-23 06:46:00 +03:00
|
|
|
|
2023-08-08 07:19:58 +03:00
|
|
|
_FDT(fdt_setprop(fdt, chosen, "rng-seed", spapr->fdt_rng_seed, 32));
|
2022-07-12 16:51:14 +03:00
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
_FDT(spapr_dt_ovec(fdt, chosen, spapr->ov5_cas, "ibm,architecture-vec-5"));
|
2016-10-24 04:05:57 +03: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 07:35:37 +03:00
|
|
|
static void spapr_dt_hypervisor(SpaprMachineState *spapr, void *fdt)
|
2016-10-20 07:59:36 +03:00
|
|
|
{
|
|
|
|
/* The /hypervisor node isn't in PAPR - this is a hack to allow PR
|
|
|
|
* KVM to work under pHyp with some guest co-operation */
|
|
|
|
int hypervisor;
|
|
|
|
uint8_t hypercall[16];
|
|
|
|
|
|
|
|
_FDT(hypervisor = fdt_add_subnode(fdt, 0, "hypervisor"));
|
|
|
|
/* indicate KVM hypercall interface */
|
|
|
|
_FDT(fdt_setprop_string(fdt, hypervisor, "compatible", "linux,kvm"));
|
|
|
|
if (kvmppc_has_cap_fixup_hcalls()) {
|
|
|
|
/*
|
|
|
|
* Older KVM versions with older guest kernels were broken
|
|
|
|
* with the magic page, don't allow the guest to map it.
|
|
|
|
*/
|
2023-09-14 03:22:49 +03:00
|
|
|
if (!kvmppc_get_hypercall(cpu_env(first_cpu), hypercall,
|
2016-10-20 07:59:36 +03:00
|
|
|
sizeof(hypercall))) {
|
|
|
|
_FDT(fdt_setprop(fdt, hypervisor, "hcall-instructions",
|
|
|
|
hypercall, sizeof(hypercall)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-29 07:00:58 +03:00
|
|
|
void *spapr_build_fdt(SpaprMachineState *spapr, bool reset, size_t space)
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
{
|
2017-09-06 21:43:05 +03:00
|
|
|
MachineState *machine = MACHINE(spapr);
|
2016-08-05 09:25:33 +03:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(machine);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
|
spapr: Fix DR properties of the root node
Section 13.5.2 of LoPAPR mandates various DR related indentifiers
for all hot-pluggable entities to be exposed in the "ibm,drc-indexes",
"ibm,drc-power-domains", "ibm,drc-names" and "ibm,drc-types" properties
of their parent node. These properties are created with spapr_dt_drc().
PHBs and LMBs are both children of the machine. Their DR identifiers
are thus supposed to be exposed in the afore mentioned properties of
the root node.
When PHB hot-plug support was added, an extra call to spapr_dt_drc()
was introduced: this overwrites the existing properties, previously
populated with the LMB identifiers, and they end up containing only
PHB identifiers. This went unseen so far because linux doesn't care,
but this is still not conformant with LoPAPR.
Fortunately spapr_dt_drc() is able to handle multiple DR entity types
at the same time. Use that to handle DR indentifiers for PHBs and LMBs
with a single call to spapr_dt_drc(). While here also account for PMEM
DR identifiers, which were forgotten when NVDIMM hot-plug support was
added. Also add an assert to prevent further misuse of spapr_dt_drc().
With -m 1G,maxmem=2G,slots=8 passed on the QEMU command line we get:
Without this patch:
/proc/device-tree/ibm,drc-indexes
0000001f 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
These are the DRC indexes for the 31 possible PHBs.
With this patch:
/proc/device-tree/ibm,drc-indexes
0000002b 90000000 90000001 90000002
90000003 90000004 90000005 90000006
90000007 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
80000004 80000005 80000006 80000007
And now we also have the 4 ((2G - 1G) / 256M) LMBs and the
8 (slots) PMEMs.
Fixes: 3998ccd09298 ("spapr: populate PHB DRC entries for root DT node")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160794479566.35245.17809158217760761558.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-12-14 14:19:55 +03:00
|
|
|
uint32_t root_drc_type_mask = 0;
|
2016-10-24 04:05:57 +03:00
|
|
|
int ret;
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
void *fdt;
|
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 07:35:37 +03:00
|
|
|
SpaprPhbState *phb;
|
2016-10-20 08:05:00 +03:00
|
|
|
char *buf;
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
|
2019-10-18 13:25:49 +03:00
|
|
|
fdt = g_malloc0(space);
|
|
|
|
_FDT((fdt_create_empty_tree(fdt, space)));
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
|
2016-10-20 08:05:00 +03:00
|
|
|
/* Root node */
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "device_type", "chrp"));
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "model", "IBM pSeries (emulated by qemu)"));
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "compatible", "qemu,pseries"));
|
|
|
|
|
2019-03-27 05:54:11 +03:00
|
|
|
/* Guest UUID & Name*/
|
2016-10-20 08:05:00 +03:00
|
|
|
buf = qemu_uuid_unparse_strdup(&qemu_uuid);
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "vm,uuid", buf));
|
|
|
|
if (qemu_uuid_set) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "system-id", buf));
|
|
|
|
}
|
|
|
|
g_free(buf);
|
|
|
|
|
|
|
|
if (qemu_get_vm_name()) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "ibm,partition-name",
|
|
|
|
qemu_get_vm_name()));
|
|
|
|
}
|
|
|
|
|
2019-03-27 05:54:11 +03:00
|
|
|
/* Host Model & Serial Number */
|
|
|
|
if (spapr->host_model) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "host-model", spapr->host_model));
|
|
|
|
} else if (smc->broken_host_serial_model && kvmppc_get_host_model(&buf)) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "host-model", buf));
|
|
|
|
g_free(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (spapr->host_serial) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "host-serial", spapr->host_serial));
|
|
|
|
} else if (smc->broken_host_serial_model && kvmppc_get_host_serial(&buf)) {
|
|
|
|
_FDT(fdt_setprop_string(fdt, 0, "host-serial", buf));
|
|
|
|
g_free(buf);
|
|
|
|
}
|
|
|
|
|
2016-10-20 08:05:00 +03:00
|
|
|
_FDT(fdt_setprop_cell(fdt, 0, "#address-cells", 2));
|
|
|
|
_FDT(fdt_setprop_cell(fdt, 0, "#size-cells", 2));
|
2011-04-01 08:15:21 +04:00
|
|
|
|
2017-07-28 06:38:50 +03:00
|
|
|
/* /interrupt controller */
|
2019-09-30 05:35:06 +03:00
|
|
|
spapr_irq_dt(spapr, spapr_max_server_number(spapr), fdt, PHANDLE_INTC);
|
2017-07-28 06:38:50 +03:00
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
ret = spapr_dt_memory(spapr, fdt);
|
2015-08-03 08:35:41 +03:00
|
|
|
if (ret < 0) {
|
2016-08-02 20:38:00 +03:00
|
|
|
error_report("couldn't setup memory nodes in fdt");
|
2015-08-03 08:35:41 +03:00
|
|
|
exit(1);
|
2012-09-12 20:57:12 +04:00
|
|
|
}
|
|
|
|
|
2016-10-20 08:01:17 +03:00
|
|
|
/* /vdevice */
|
|
|
|
spapr_dt_vdevice(spapr->vio_bus, fdt);
|
2011-04-01 08:15:21 +04:00
|
|
|
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
if (object_resolve_path_type("", TYPE_SPAPR_RNG, NULL)) {
|
2020-01-22 08:15:43 +03:00
|
|
|
ret = spapr_dt_rng(fdt);
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
if (ret < 0) {
|
2016-08-02 20:38:00 +03:00
|
|
|
error_report("could not set up rng device in the fdt");
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-10-30 21:16:46 +04:00
|
|
|
QLIST_FOREACH(phb, &spapr->phbs, list) {
|
2019-09-27 06:44:58 +03:00
|
|
|
ret = spapr_dt_phb(spapr, phb, PHANDLE_INTC, fdt, NULL);
|
2016-04-21 13:08:58 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
error_report("couldn't setup PCI devices in fdt");
|
|
|
|
exit(1);
|
|
|
|
}
|
2011-10-30 21:16:46 +04:00
|
|
|
}
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
spapr_dt_cpus(fdt, spapr);
|
2011-12-12 22:24:30 +04:00
|
|
|
|
spapr: Fix DR properties of the root node
Section 13.5.2 of LoPAPR mandates various DR related indentifiers
for all hot-pluggable entities to be exposed in the "ibm,drc-indexes",
"ibm,drc-power-domains", "ibm,drc-names" and "ibm,drc-types" properties
of their parent node. These properties are created with spapr_dt_drc().
PHBs and LMBs are both children of the machine. Their DR identifiers
are thus supposed to be exposed in the afore mentioned properties of
the root node.
When PHB hot-plug support was added, an extra call to spapr_dt_drc()
was introduced: this overwrites the existing properties, previously
populated with the LMB identifiers, and they end up containing only
PHB identifiers. This went unseen so far because linux doesn't care,
but this is still not conformant with LoPAPR.
Fortunately spapr_dt_drc() is able to handle multiple DR entity types
at the same time. Use that to handle DR indentifiers for PHBs and LMBs
with a single call to spapr_dt_drc(). While here also account for PMEM
DR identifiers, which were forgotten when NVDIMM hot-plug support was
added. Also add an assert to prevent further misuse of spapr_dt_drc().
With -m 1G,maxmem=2G,slots=8 passed on the QEMU command line we get:
Without this patch:
/proc/device-tree/ibm,drc-indexes
0000001f 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
These are the DRC indexes for the 31 possible PHBs.
With this patch:
/proc/device-tree/ibm,drc-indexes
0000002b 90000000 90000001 90000002
90000003 90000004 90000005 90000006
90000007 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
80000004 80000005 80000006 80000007
And now we also have the 4 ((2G - 1G) / 256M) LMBs and the
8 (slots) PMEMs.
Fixes: 3998ccd09298 ("spapr: populate PHB DRC entries for root DT node")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160794479566.35245.17809158217760761558.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-12-14 14:19:55 +03:00
|
|
|
/* ibm,drc-indexes and friends */
|
2015-09-01 04:22:35 +03:00
|
|
|
if (smc->dr_lmb_enabled) {
|
spapr: Fix DR properties of the root node
Section 13.5.2 of LoPAPR mandates various DR related indentifiers
for all hot-pluggable entities to be exposed in the "ibm,drc-indexes",
"ibm,drc-power-domains", "ibm,drc-names" and "ibm,drc-types" properties
of their parent node. These properties are created with spapr_dt_drc().
PHBs and LMBs are both children of the machine. Their DR identifiers
are thus supposed to be exposed in the afore mentioned properties of
the root node.
When PHB hot-plug support was added, an extra call to spapr_dt_drc()
was introduced: this overwrites the existing properties, previously
populated with the LMB identifiers, and they end up containing only
PHB identifiers. This went unseen so far because linux doesn't care,
but this is still not conformant with LoPAPR.
Fortunately spapr_dt_drc() is able to handle multiple DR entity types
at the same time. Use that to handle DR indentifiers for PHBs and LMBs
with a single call to spapr_dt_drc(). While here also account for PMEM
DR identifiers, which were forgotten when NVDIMM hot-plug support was
added. Also add an assert to prevent further misuse of spapr_dt_drc().
With -m 1G,maxmem=2G,slots=8 passed on the QEMU command line we get:
Without this patch:
/proc/device-tree/ibm,drc-indexes
0000001f 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
These are the DRC indexes for the 31 possible PHBs.
With this patch:
/proc/device-tree/ibm,drc-indexes
0000002b 90000000 90000001 90000002
90000003 90000004 90000005 90000006
90000007 20000001 20000002 20000003
20000000 20000005 20000006 20000007
20000004 20000009 20000008 20000010
20000011 20000012 20000013 20000014
20000015 20000016 20000017 20000018
20000019 2000000a 2000000b 2000000c
2000000d 2000000e 2000000f 2000001a
2000001b 2000001c 2000001d 2000001e
80000004 80000005 80000006 80000007
And now we also have the 4 ((2G - 1G) / 256M) LMBs and the
8 (slots) PMEMs.
Fixes: 3998ccd09298 ("spapr: populate PHB DRC entries for root DT node")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <160794479566.35245.17809158217760761558.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-12-14 14:19:55 +03:00
|
|
|
root_drc_type_mask |= SPAPR_DR_CONNECTOR_TYPE_LMB;
|
|
|
|
}
|
|
|
|
if (smc->dr_phb_enabled) {
|
|
|
|
root_drc_type_mask |= SPAPR_DR_CONNECTOR_TYPE_PHB;
|
|
|
|
}
|
|
|
|
if (mc->nvdimm_supported) {
|
|
|
|
root_drc_type_mask |= SPAPR_DR_CONNECTOR_TYPE_PMEM;
|
|
|
|
}
|
|
|
|
if (root_drc_type_mask) {
|
|
|
|
_FDT(spapr_dt_drc(fdt, 0, NULL, root_drc_type_mask));
|
2015-09-01 04:22:35 +03:00
|
|
|
}
|
|
|
|
|
2017-02-10 13:20:57 +03:00
|
|
|
if (mc->has_hotpluggable_cpus) {
|
2016-06-10 03:59:04 +03:00
|
|
|
int offset = fdt_path_offset(fdt, "/cpus");
|
2019-04-10 09:11:40 +03:00
|
|
|
ret = spapr_dt_drc(fdt, offset, NULL, SPAPR_DR_CONNECTOR_TYPE_CPU);
|
2016-06-10 03:59:04 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
error_report("Couldn't set up CPU DR device tree properties");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-20 07:56:48 +03:00
|
|
|
/* /event-sources */
|
2016-10-27 05:20:26 +03:00
|
|
|
spapr_dt_events(spapr, fdt);
|
2016-10-20 07:56:48 +03:00
|
|
|
|
2016-10-20 07:55:36 +03:00
|
|
|
/* /rtas */
|
|
|
|
spapr_dt_rtas(spapr, fdt);
|
|
|
|
|
2016-10-24 04:05:57 +03:00
|
|
|
/* /chosen */
|
2020-01-22 07:50:42 +03:00
|
|
|
spapr_dt_chosen(spapr, fdt, reset);
|
2016-10-20 07:34:59 +03:00
|
|
|
|
2016-10-20 07:59:36 +03:00
|
|
|
/* /hypervisor */
|
|
|
|
if (kvm_enabled()) {
|
|
|
|
spapr_dt_hypervisor(spapr, fdt);
|
|
|
|
}
|
|
|
|
|
2016-10-20 07:34:59 +03:00
|
|
|
/* Build memory reserve map */
|
2019-10-24 07:13:08 +03:00
|
|
|
if (reset) {
|
|
|
|
if (spapr->kernel_size) {
|
2020-02-03 06:29:42 +03:00
|
|
|
_FDT((fdt_add_mem_rsv(fdt, spapr->kernel_addr,
|
|
|
|
spapr->kernel_size)));
|
2019-10-24 07:13:08 +03:00
|
|
|
}
|
|
|
|
if (spapr->initrd_size) {
|
|
|
|
_FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base,
|
|
|
|
spapr->initrd_size)));
|
|
|
|
}
|
2016-10-20 07:34:59 +03:00
|
|
|
}
|
|
|
|
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
/* NVDIMM devices */
|
|
|
|
if (mc->nvdimm_supported) {
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
spapr_dt_persistent_memory(spapr, fdt);
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
}
|
|
|
|
|
2016-10-25 03:51:33 +03:00
|
|
|
return fdt;
|
2011-04-01 08:15:20 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static uint64_t translate_kernel_address(void *opaque, uint64_t addr)
|
|
|
|
{
|
2020-02-03 06:29:42 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
|
|
|
|
|
|
|
return (addr & 0x0fffffff) + spapr->kernel_addr;
|
2011-04-01 08:15:20 +04:00
|
|
|
}
|
|
|
|
|
2016-10-28 14:06:21 +03:00
|
|
|
static void emulate_spapr_hypercall(PPCVirtualHypervisor *vhyp,
|
|
|
|
PowerPCCPU *cpu)
|
2011-04-01 08:15:20 +04:00
|
|
|
{
|
2012-05-03 08:03:45 +04:00
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
|
tcg: drop global lock during TCG code execution
This finally allows TCG to benefit from the iothread introduction: Drop
the global mutex while running pure TCG CPU code. Reacquire the lock
when entering MMIO or PIO emulation, or when leaving the TCG loop.
We have to revert a few optimization for the current TCG threading
model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not
kicking it in qemu_cpu_kick. We also need to disable RAM block
reordering until we have a more efficient locking mechanism at hand.
Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here.
These numbers demonstrate where we gain something:
20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm
20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm
The guest CPU was fully loaded, but the iothread could still run mostly
independent on a second core. Without the patch we don't get beyond
32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm
32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm
We don't benefit significantly, though, when the guest is not fully
loading a host CPU.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.com>
[FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex]
Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com>
[EGC: fixed iothread lock for cpu-exec IRQ handling]
Signed-off-by: Emilio G. Cota <cota@braap.org>
[AJB: -smp single-threaded fix, clean commit msg, BQL fixes]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
[PM: target-arm changes]
Acked-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-23 21:29:11 +03:00
|
|
|
/* The TCG path should also be holding the BQL at this point */
|
2024-01-02 18:35:25 +03:00
|
|
|
g_assert(bql_locked());
|
tcg: drop global lock during TCG code execution
This finally allows TCG to benefit from the iothread introduction: Drop
the global mutex while running pure TCG CPU code. Reacquire the lock
when entering MMIO or PIO emulation, or when leaving the TCG loop.
We have to revert a few optimization for the current TCG threading
model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not
kicking it in qemu_cpu_kick. We also need to disable RAM block
reordering until we have a more efficient locking mechanism at hand.
Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here.
These numbers demonstrate where we gain something:
20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm
20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm
The guest CPU was fully loaded, but the iothread could still run mostly
independent on a second core. Without the patch we don't get beyond
32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm
32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm
We don't benefit significantly, though, when the guest is not fully
loading a host CPU.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.com>
[FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex]
Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com>
[EGC: fixed iothread lock for cpu-exec IRQ handling]
Signed-off-by: Emilio G. Cota <cota@braap.org>
[AJB: -smp single-threaded fix, clean commit msg, BQL fixes]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Reviewed-by: Pranith Kumar <bobby.prani@gmail.com>
[PM: target-arm changes]
Acked-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-23 21:29:11 +03:00
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
g_assert(!vhyp_cpu_in_nested(cpu));
|
|
|
|
|
2022-05-05 00:05:22 +03:00
|
|
|
if (FIELD_EX64(env->msr, MSR, PR)) {
|
2012-09-25 21:12:20 +04:00
|
|
|
hcall_dprintf("Hypercall made with MSR[PR]=1\n");
|
|
|
|
env->gpr[3] = H_PRIVILEGE;
|
|
|
|
} else {
|
2012-05-03 08:13:14 +04:00
|
|
|
env->gpr[3] = spapr_hypercall(cpu, env->gpr[3], &env->gpr[4]);
|
2012-09-25 21:12:20 +04:00
|
|
|
}
|
2011-04-01 08:15:20 +04:00
|
|
|
}
|
|
|
|
|
2019-02-15 20:00:18 +03:00
|
|
|
struct LPCRSyncState {
|
|
|
|
target_ulong value;
|
|
|
|
target_ulong mask;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void do_lpcr_sync(CPUState *cs, run_on_cpu_data arg)
|
|
|
|
{
|
|
|
|
struct LPCRSyncState *s = arg.host_ptr;
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
target_ulong lpcr;
|
|
|
|
|
|
|
|
cpu_synchronize_state(cs);
|
|
|
|
lpcr = env->spr[SPR_LPCR];
|
|
|
|
lpcr &= ~s->mask;
|
|
|
|
lpcr |= s->value;
|
|
|
|
ppc_store_lpcr(cpu, lpcr);
|
|
|
|
}
|
|
|
|
|
|
|
|
void spapr_set_all_lpcrs(target_ulong value, target_ulong mask)
|
|
|
|
{
|
|
|
|
CPUState *cs;
|
|
|
|
struct LPCRSyncState s = {
|
|
|
|
.value = value,
|
|
|
|
.mask = mask
|
|
|
|
};
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
run_on_cpu(cs, do_lpcr_sync, RUN_ON_CPU_HOST_PTR(&s));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-08-08 07:19:57 +03:00
|
|
|
/* May be used when the machine is not running */
|
|
|
|
void spapr_init_all_lpcrs(target_ulong value, target_ulong mask)
|
|
|
|
{
|
|
|
|
CPUState *cs;
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
|
|
|
target_ulong lpcr;
|
|
|
|
|
|
|
|
lpcr = env->spr[SPR_LPCR];
|
|
|
|
lpcr &= ~(LPCR_HR | LPCR_UPRT);
|
|
|
|
ppc_store_lpcr(cpu, lpcr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
static bool spapr_get_pate(PPCVirtualHypervisor *vhyp, PowerPCCPU *cpu,
|
|
|
|
target_ulong lpid, ppc_v3_pate_t *entry)
|
2017-03-01 09:54:36 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
2022-02-18 10:34:14 +03:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
2017-03-01 09:54:36 +03:00
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
if (!spapr_cpu->in_nested) {
|
|
|
|
assert(lpid == 0);
|
2022-02-18 10:34:14 +03:00
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
/* Copy PATE1:GR into PATE0:HR */
|
|
|
|
entry->dw0 = spapr->patb_entry & PATE0_HR;
|
|
|
|
entry->dw1 = spapr->patb_entry;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
uint64_t patb, pats;
|
|
|
|
|
|
|
|
assert(lpid != 0);
|
|
|
|
|
|
|
|
patb = spapr->nested_ptcr & PTCR_PATB;
|
|
|
|
pats = spapr->nested_ptcr & PTCR_PATS;
|
|
|
|
|
2022-06-28 16:39:57 +03:00
|
|
|
/* Check if partition table is properly aligned */
|
|
|
|
if (patb & MAKE_64BIT_MASK(0, pats + 12)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
/* Calculate number of entries */
|
|
|
|
pats = 1ull << (pats + 12 - 4);
|
|
|
|
if (pats <= lpid) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Grab entry */
|
|
|
|
patb += 16 * lpid;
|
|
|
|
entry->dw0 = ldq_phys(CPU(cpu)->as, patb);
|
|
|
|
entry->dw1 = ldq_phys(CPU(cpu)->as, patb + 8);
|
|
|
|
}
|
2022-02-18 10:34:14 +03:00
|
|
|
|
|
|
|
return true;
|
2017-03-01 09:54:36 +03:00
|
|
|
}
|
|
|
|
|
2014-11-17 07:12:30 +03:00
|
|
|
#define HPTE(_table, _i) (void *)(((uint64_t *)(_table)) + ((_i) * 2))
|
|
|
|
#define HPTE_VALID(_hpte) (tswap64(*((uint64_t *)(_hpte))) & HPTE64_V_VALID)
|
|
|
|
#define HPTE_DIRTY(_hpte) (tswap64(*((uint64_t *)(_hpte))) & HPTE64_V_HPTE_DIRTY)
|
|
|
|
#define CLEAN_HPTE(_hpte) ((*(uint64_t *)(_hpte)) &= tswap64(~HPTE64_V_HPTE_DIRTY))
|
|
|
|
#define DIRTY_HPTE(_hpte) ((*(uint64_t *)(_hpte)) |= tswap64(HPTE64_V_HPTE_DIRTY))
|
|
|
|
|
2016-02-09 02:28:58 +03:00
|
|
|
/*
|
|
|
|
* Get the fd to access the kernel htab, re-opening it if necessary
|
|
|
|
*/
|
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 07:35:37 +03:00
|
|
|
static int get_htab_fd(SpaprMachineState *spapr)
|
2016-02-09 02:28:58 +03:00
|
|
|
{
|
2017-09-15 16:16:20 +03:00
|
|
|
Error *local_err = NULL;
|
|
|
|
|
2016-02-09 02:28:58 +03:00
|
|
|
if (spapr->htab_fd >= 0) {
|
|
|
|
return spapr->htab_fd;
|
|
|
|
}
|
|
|
|
|
2017-09-15 16:16:20 +03:00
|
|
|
spapr->htab_fd = kvmppc_get_htab_fd(false, 0, &local_err);
|
2016-02-09 02:28:58 +03:00
|
|
|
if (spapr->htab_fd < 0) {
|
2017-09-15 16:16:20 +03:00
|
|
|
error_report_err(local_err);
|
2016-02-09 02:28:58 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return spapr->htab_fd;
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
void close_htab_fd(SpaprMachineState *spapr)
|
2016-02-09 02:28:58 +03:00
|
|
|
{
|
|
|
|
if (spapr->htab_fd >= 0) {
|
|
|
|
close(spapr->htab_fd);
|
|
|
|
}
|
|
|
|
spapr->htab_fd = -1;
|
|
|
|
}
|
|
|
|
|
2017-02-23 03:39:18 +03:00
|
|
|
static hwaddr spapr_hpt_mask(PPCVirtualHypervisor *vhyp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
2017-02-23 03:39:18 +03:00
|
|
|
|
|
|
|
return HTAB_SIZE(spapr) / HASH_PTEG_SIZE_64 - 1;
|
|
|
|
}
|
|
|
|
|
2017-09-25 14:00:02 +03:00
|
|
|
static target_ulong spapr_encode_hpt_for_kvm_pr(PPCVirtualHypervisor *vhyp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
2017-09-25 14:00:02 +03:00
|
|
|
|
|
|
|
assert(kvm_enabled());
|
|
|
|
|
|
|
|
if (!spapr->htab) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (target_ulong)(uintptr_t)spapr->htab | (spapr->htab_shift - 18);
|
|
|
|
}
|
|
|
|
|
2017-02-23 03:39:18 +03:00
|
|
|
static const ppc_hash_pte64_t *spapr_map_hptes(PPCVirtualHypervisor *vhyp,
|
|
|
|
hwaddr ptex, int n)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
2017-02-23 03:39:18 +03:00
|
|
|
hwaddr pte_offset = ptex * HASH_PTE_SIZE_64;
|
|
|
|
|
|
|
|
if (!spapr->htab) {
|
|
|
|
/*
|
|
|
|
* HTAB is controlled by KVM. Fetch into temporary buffer
|
|
|
|
*/
|
|
|
|
ppc_hash_pte64_t *hptes = g_malloc(n * HASH_PTE_SIZE_64);
|
|
|
|
kvmppc_read_hptes(hptes, ptex, n);
|
|
|
|
return hptes;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HTAB is controlled by QEMU. Just point to the internally
|
|
|
|
* accessible PTEG.
|
|
|
|
*/
|
|
|
|
return (const ppc_hash_pte64_t *)(spapr->htab + pte_offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_unmap_hptes(PPCVirtualHypervisor *vhyp,
|
|
|
|
const ppc_hash_pte64_t *hptes,
|
|
|
|
hwaddr ptex, int n)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
2017-02-23 03:39:18 +03:00
|
|
|
|
|
|
|
if (!spapr->htab) {
|
|
|
|
g_free((void *)hptes);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Nothing to do for qemu managed HPT */
|
|
|
|
}
|
|
|
|
|
2019-04-11 11:00:01 +03:00
|
|
|
void spapr_store_hpte(PowerPCCPU *cpu, hwaddr ptex,
|
|
|
|
uint64_t pte0, uint64_t pte1)
|
2017-02-23 03:39:18 +03:00
|
|
|
{
|
2019-04-11 11:00:01 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(cpu->vhyp);
|
2017-02-23 03:39:18 +03:00
|
|
|
hwaddr offset = ptex * HASH_PTE_SIZE_64;
|
|
|
|
|
|
|
|
if (!spapr->htab) {
|
|
|
|
kvmppc_write_hpte(ptex, pte0, pte1);
|
|
|
|
} else {
|
2019-02-15 20:00:23 +03:00
|
|
|
if (pte0 & HPTE64_V_VALID) {
|
2021-11-29 21:57:51 +03:00
|
|
|
stq_p(spapr->htab + offset + HPTE64_DW1, pte1);
|
2019-02-15 20:00:23 +03:00
|
|
|
/*
|
|
|
|
* When setting valid, we write PTE1 first. This ensures
|
|
|
|
* proper synchronization with the reading code in
|
|
|
|
* ppc_hash64_pteg_search()
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
stq_p(spapr->htab + offset, pte0);
|
|
|
|
} else {
|
|
|
|
stq_p(spapr->htab + offset, pte0);
|
|
|
|
/*
|
|
|
|
* When clearing it we set PTE0 first. This ensures proper
|
|
|
|
* synchronization with the reading code in
|
|
|
|
* ppc_hash64_pteg_search()
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
2021-11-29 21:57:51 +03:00
|
|
|
stq_p(spapr->htab + offset + HPTE64_DW1, pte1);
|
2019-02-15 20:00:23 +03:00
|
|
|
}
|
2017-02-23 03:39:18 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-11 11:00:01 +03:00
|
|
|
static void spapr_hpte_set_c(PPCVirtualHypervisor *vhyp, hwaddr ptex,
|
|
|
|
uint64_t pte1)
|
|
|
|
{
|
2021-11-29 21:57:51 +03:00
|
|
|
hwaddr offset = ptex * HASH_PTE_SIZE_64 + HPTE64_DW1_C;
|
2019-04-11 11:00:01 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
|
|
|
|
|
|
|
if (!spapr->htab) {
|
|
|
|
/* There should always be a hash table when this is called */
|
|
|
|
error_report("spapr_hpte_set_c called with no hash table !");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The HW performs a non-atomic byte update */
|
|
|
|
stb_p(spapr->htab + offset, (pte1 & 0xff) | 0x80);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_hpte_set_r(PPCVirtualHypervisor *vhyp, hwaddr ptex,
|
|
|
|
uint64_t pte1)
|
|
|
|
{
|
2021-11-29 21:57:51 +03:00
|
|
|
hwaddr offset = ptex * HASH_PTE_SIZE_64 + HPTE64_DW1_R;
|
2019-04-11 11:00:01 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(vhyp);
|
|
|
|
|
|
|
|
if (!spapr->htab) {
|
|
|
|
/* There should always be a hash table when this is called */
|
|
|
|
error_report("spapr_hpte_set_r called with no hash table !");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The HW performs a non-atomic byte update */
|
|
|
|
stb_p(spapr->htab + offset, ((pte1 >> 8) & 0xff) | 0x01);
|
|
|
|
}
|
|
|
|
|
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 08:46:49 +03:00
|
|
|
int spapr_hpt_shift_for_ramsize(uint64_t ramsize)
|
2016-02-09 03:15:12 +03:00
|
|
|
{
|
|
|
|
int shift;
|
|
|
|
|
|
|
|
/* We aim for a hash table of size 1/128 the size of RAM (rounded
|
|
|
|
* up). The PAPR recommendation is actually 1/64 of RAM size, but
|
|
|
|
* that's much more than is needed for Linux guests */
|
|
|
|
shift = ctz64(pow2ceil(ramsize)) - 7;
|
|
|
|
shift = MAX(shift, 18); /* Minimum architected size */
|
|
|
|
shift = MIN(shift, 46); /* Maximum architected size */
|
|
|
|
return shift;
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
void spapr_free_hpt(SpaprMachineState *spapr)
|
2017-05-17 06:49:20 +03:00
|
|
|
{
|
2022-09-20 13:31:47 +03:00
|
|
|
qemu_vfree(spapr->htab);
|
2017-05-17 06:49:20 +03:00
|
|
|
spapr->htab = NULL;
|
|
|
|
spapr->htab_shift = 0;
|
|
|
|
close_htab_fd(spapr);
|
|
|
|
}
|
|
|
|
|
2020-10-26 15:40:54 +03:00
|
|
|
int spapr_reallocate_hpt(SpaprMachineState *spapr, int shift, Error **errp)
|
2012-09-12 20:57:12 +04:00
|
|
|
{
|
2020-10-26 15:40:40 +03:00
|
|
|
ERRP_GUARD();
|
2016-02-09 03:21:56 +03:00
|
|
|
long rc;
|
|
|
|
|
|
|
|
/* Clean up any HPT info from a previous boot */
|
2017-05-17 06:49:20 +03:00
|
|
|
spapr_free_hpt(spapr);
|
2016-02-09 03:21:56 +03:00
|
|
|
|
|
|
|
rc = kvmppc_reset_htab(shift);
|
2020-09-11 07:31:23 +03:00
|
|
|
|
|
|
|
if (rc == -EOPNOTSUPP) {
|
|
|
|
error_setg(errp, "HPT not supported in nested guests");
|
2020-10-26 15:40:54 +03:00
|
|
|
return -EOPNOTSUPP;
|
2020-09-11 07:31:23 +03:00
|
|
|
}
|
|
|
|
|
2016-02-09 03:21:56 +03:00
|
|
|
if (rc < 0) {
|
|
|
|
/* kernel-side HPT needed, but couldn't allocate one */
|
2020-10-26 15:40:40 +03:00
|
|
|
error_setg_errno(errp, errno, "Failed to allocate KVM HPT of order %d",
|
2016-02-09 03:21:56 +03:00
|
|
|
shift);
|
2020-10-26 15:40:40 +03:00
|
|
|
error_append_hint(errp, "Try smaller maxmem?\n");
|
2020-10-26 15:40:54 +03:00
|
|
|
return -errno;
|
2016-02-09 03:21:56 +03:00
|
|
|
} else if (rc > 0) {
|
|
|
|
/* kernel-side HPT allocated */
|
|
|
|
if (rc != shift) {
|
|
|
|
error_setg(errp,
|
2020-10-26 15:40:40 +03:00
|
|
|
"Requested order %d HPT, but kernel allocated order %ld",
|
2016-02-09 03:21:56 +03:00
|
|
|
shift, rc);
|
2020-10-26 15:40:40 +03:00
|
|
|
error_append_hint(errp, "Try smaller maxmem?\n");
|
2020-10-26 15:40:54 +03:00
|
|
|
return -ENOSPC;
|
2015-09-24 11:22:48 +03:00
|
|
|
}
|
|
|
|
|
2012-09-12 20:57:12 +04:00
|
|
|
spapr->htab_shift = shift;
|
2016-03-08 03:35:15 +03:00
|
|
|
spapr->htab = NULL;
|
2015-09-24 11:22:47 +03:00
|
|
|
} else {
|
2016-02-09 03:21:56 +03:00
|
|
|
/* kernel-side HPT not needed, allocate in userspace instead */
|
|
|
|
size_t size = 1ULL << shift;
|
|
|
|
int i;
|
2015-09-24 11:22:47 +03:00
|
|
|
|
2016-02-09 03:21:56 +03:00
|
|
|
spapr->htab = qemu_memalign(size, size);
|
|
|
|
memset(spapr->htab, 0, size);
|
|
|
|
spapr->htab_shift = shift;
|
2014-11-17 07:12:30 +03:00
|
|
|
|
2016-02-09 03:21:56 +03:00
|
|
|
for (i = 0; i < size / HASH_PTE_SIZE_64; i++) {
|
|
|
|
DIRTY_HPTE(HPTE(spapr->htab, i));
|
2014-11-17 07:12:30 +03:00
|
|
|
}
|
2012-09-12 20:57:12 +04:00
|
|
|
}
|
2017-11-24 07:23:24 +03:00
|
|
|
/* We're setting up a hash table, so that means we're not radix */
|
2019-03-05 05:21:02 +03:00
|
|
|
spapr->patb_entry = 0;
|
2023-08-08 07:19:57 +03:00
|
|
|
spapr_init_all_lpcrs(0, LPCR_HR | LPCR_UPRT);
|
2020-10-26 15:40:54 +03:00
|
|
|
return 0;
|
2011-04-01 08:15:20 +04:00
|
|
|
}
|
|
|
|
|
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 08:37:04 +03:00
|
|
|
void spapr_setup_hpt(SpaprMachineState *spapr)
|
2017-03-20 02:46:46 +03:00
|
|
|
{
|
2017-07-12 10:56:06 +03:00
|
|
|
int hpt_shift;
|
|
|
|
|
2020-03-25 18:25:49 +03:00
|
|
|
if (spapr->resize_hpt == SPAPR_RESIZE_HPT_DISABLED) {
|
2017-07-12 10:56:06 +03:00
|
|
|
hpt_shift = spapr_hpt_shift_for_ramsize(MACHINE(spapr)->maxram_size);
|
|
|
|
} else {
|
2017-12-01 08:05:33 +03:00
|
|
|
uint64_t current_ram_size;
|
|
|
|
|
|
|
|
current_ram_size = MACHINE(spapr)->ram_size + get_plugged_memory_size();
|
|
|
|
hpt_shift = spapr_hpt_shift_for_ramsize(current_ram_size);
|
2017-07-12 10:56:06 +03:00
|
|
|
}
|
|
|
|
spapr_reallocate_hpt(spapr, hpt_shift, &error_fatal);
|
|
|
|
|
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 08:37:04 +03:00
|
|
|
if (kvm_enabled()) {
|
2019-11-28 08:12:06 +03:00
|
|
|
hwaddr vrma_limit = kvmppc_vrma_limit(spapr->htab_shift);
|
|
|
|
|
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 08:37:04 +03:00
|
|
|
/* Check our RMA fits in the possible VRMA */
|
|
|
|
if (vrma_limit < spapr->rma_size) {
|
|
|
|
error_report("Unable to create %" HWADDR_PRIu
|
|
|
|
"MiB RMA (VRMA only allows %" HWADDR_PRIu "MiB",
|
|
|
|
spapr->rma_size / MiB, vrma_limit / MiB);
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
2017-03-20 02:46:46 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-05 03:11:29 +03:00
|
|
|
void spapr_check_mmu_mode(bool guest_radix)
|
|
|
|
{
|
|
|
|
if (guest_radix) {
|
|
|
|
if (kvm_enabled() && !kvmppc_has_cap_mmu_radix()) {
|
|
|
|
error_report("Guest requested unavailable MMU mode (radix).");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (kvm_enabled() && kvmppc_has_cap_mmu_radix()
|
|
|
|
&& !kvmppc_has_cap_mmu_hash_v3()) {
|
|
|
|
error_report("Guest requested unavailable MMU mode (hash).");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-25 03:43:17 +03:00
|
|
|
static void spapr_machine_reset(MachineState *machine, ShutdownCause reason)
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(machine);
|
2013-05-30 00:29:20 +04:00
|
|
|
PowerPCCPU *first_ppc_cpu;
|
2019-07-16 08:27:43 +03:00
|
|
|
hwaddr fdt_addr;
|
2016-10-25 03:51:33 +03:00
|
|
|
void *fdt;
|
|
|
|
int rc;
|
2013-01-17 21:51:17 +04:00
|
|
|
|
2023-08-08 07:19:58 +03:00
|
|
|
if (reason != SHUTDOWN_CAUSE_SNAPSHOT_LOAD) {
|
|
|
|
/*
|
|
|
|
* Record-replay snapshot load must not consume random, this was
|
|
|
|
* already replayed from initial machine reset.
|
|
|
|
*/
|
|
|
|
qemu_guest_getrandom_nofail(spapr->fdt_rng_seed, 32);
|
|
|
|
}
|
|
|
|
|
2020-04-08 08:10:03 +03:00
|
|
|
pef_kvm_reset(machine->cgs, &error_fatal);
|
2018-06-14 09:37:28 +03:00
|
|
|
spapr_caps_apply(spapr);
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
|
2017-12-14 21:09:48 +03:00
|
|
|
first_ppc_cpu = POWERPC_CPU(first_cpu);
|
|
|
|
if (kvm_enabled() && kvmppc_has_cap_mmu_radix() &&
|
2018-06-14 09:33:58 +03:00
|
|
|
ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00, 0,
|
|
|
|
spapr->max_compat_pvr)) {
|
2019-02-15 20:00:27 +03:00
|
|
|
/*
|
|
|
|
* If using KVM with radix mode available, VCPUs can be started
|
2017-03-20 02:46:46 +03:00
|
|
|
* without a HPT because KVM will start them in radix mode.
|
2019-02-15 20:00:27 +03:00
|
|
|
* Set the GR bit in PATE so that we know there is no HPT.
|
|
|
|
*/
|
|
|
|
spapr->patb_entry = PATE1_GR;
|
2019-02-15 20:00:18 +03:00
|
|
|
spapr_set_all_lpcrs(LPCR_HR | LPCR_UPRT, LPCR_HR | LPCR_UPRT);
|
2017-03-20 02:46:46 +03:00
|
|
|
} else {
|
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 08:37:04 +03:00
|
|
|
spapr_setup_hpt(spapr);
|
2016-02-09 03:21:56 +03:00
|
|
|
}
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
|
2022-10-25 03:43:17 +03:00
|
|
|
qemu_devices_reset(reason);
|
2019-08-13 08:59:18 +03:00
|
|
|
|
2020-03-25 18:25:49 +03:00
|
|
|
spapr_ovec_cleanup(spapr->ov5_cas);
|
|
|
|
spapr->ov5_cas = spapr_ovec_new();
|
spapr: fix device tree properties when using compatibility mode
Commit 51f84465dd98 changed the compatility mode setting logic:
- machine reset only sets compatibility mode for the boot CPU
- compatibility mode is set for other CPUs when they are put online
by the guest with the "start-cpu" RTAS call
This causes a regression for machines started with max-compat-cpu:
the device tree nodes related to secondary CPU cores contain wrong
"cpu-version" and "ibm,pa-features" values, as shown below.
Guest started on a POWER8 host with:
-smp cores=2 -machine pseries,max-cpu-compat=compat7
ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00
00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00];
cpu-version = <0x4d0200>;
^^^
second CPU core
ibm,pa-features = <0x600f63f 0xc70080c0>;
cpu-version = <0xf000003>;
^^^
boot CPU core
The second core is advertised in raw POWER8 mode. This happens because
CAS assumes all CPUs to have the same compatibility mode. Since the
boot CPU already has the requested compatibility mode, the CAS code
does not set it for the secondary one, and exposes the bogus device
tree properties in in the CAS response to the guest.
A similar situation is observed when hot-plugging a CPU core. The
related device tree properties are generated and exposed to guest
with the "ibm,configure-connector" RTAS before "start-cpu" is called.
The CPU core is advertised to the guest in raw mode as well.
It both cases, it boils down to the fact that "start-cpu" happens too
late. This can be fixed globally by propagating the compatibility mode
of the boot CPU to the other CPUs during reset. For this to work, the
compatibility mode of the boot CPU must be set before the machine code
actually resets all CPUs.
It is not needed to set the compatibility mode in "start-cpu" anymore,
so the code is dropped.
Fixes: 51f84465dd98
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17 12:20:42 +03:00
|
|
|
|
2023-08-08 07:19:57 +03:00
|
|
|
ppc_init_compat_all(spapr->max_compat_pvr, &error_fatal);
|
spapr: fix device tree properties when using compatibility mode
Commit 51f84465dd98 changed the compatility mode setting logic:
- machine reset only sets compatibility mode for the boot CPU
- compatibility mode is set for other CPUs when they are put online
by the guest with the "start-cpu" RTAS call
This causes a regression for machines started with max-compat-cpu:
the device tree nodes related to secondary CPU cores contain wrong
"cpu-version" and "ibm,pa-features" values, as shown below.
Guest started on a POWER8 host with:
-smp cores=2 -machine pseries,max-cpu-compat=compat7
ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00
00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00];
cpu-version = <0x4d0200>;
^^^
second CPU core
ibm,pa-features = <0x600f63f 0xc70080c0>;
cpu-version = <0xf000003>;
^^^
boot CPU core
The second core is advertised in raw POWER8 mode. This happens because
CAS assumes all CPUs to have the same compatibility mode. Since the
boot CPU already has the requested compatibility mode, the CAS code
does not set it for the secondary one, and exposes the bogus device
tree properties in in the CAS response to the guest.
A similar situation is observed when hot-plugging a CPU core. The
related device tree properties are generated and exposed to guest
with the "ibm,configure-connector" RTAS before "start-cpu" is called.
The CPU core is advertised to the guest in raw mode as well.
It both cases, it boils down to the fact that "start-cpu" happens too
late. This can be fixed globally by propagating the compatibility mode
of the boot CPU to the other CPUs during reset. For this to work, the
compatibility mode of the boot CPU must be set before the machine code
actually resets all CPUs.
It is not needed to set the compatibility mode in "start-cpu" anymore,
so the code is dropped.
Fixes: 51f84465dd98
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-17 12:20:42 +03:00
|
|
|
|
2018-12-12 01:38:17 +03:00
|
|
|
/*
|
|
|
|
* This is fixing some of the default configuration of the XIVE
|
|
|
|
* devices. To be called after the reset of the machine devices.
|
|
|
|
*/
|
|
|
|
spapr_irq_reset(spapr, &error_fatal);
|
|
|
|
|
2019-03-01 22:32:37 +03:00
|
|
|
/*
|
|
|
|
* There is no CAS under qtest. Simulate one to please the code that
|
|
|
|
* depends on spapr->ov5_cas. This is especially needed to test device
|
|
|
|
* unplug, so we do that before resetting the DRCs.
|
|
|
|
*/
|
|
|
|
if (qtest_enabled()) {
|
|
|
|
spapr_ovec_cleanup(spapr->ov5_cas);
|
|
|
|
spapr->ov5_cas = spapr_ovec_clone(spapr->ov5);
|
|
|
|
}
|
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
spapr_nvdimm_finish_flushes();
|
|
|
|
|
2017-11-17 15:56:48 +03:00
|
|
|
/* DRC reset may cause a device to be unplugged. This will cause troubles
|
|
|
|
* if this device is used by another device (eg, a running vhost backend
|
|
|
|
* will crash QEMU if the DIMM holding the vring goes away). To avoid such
|
|
|
|
* situations, we reset DRCs after all devices have been reset.
|
|
|
|
*/
|
2020-12-18 13:33:58 +03:00
|
|
|
spapr_drc_reset_all(spapr);
|
2017-11-17 15:56:48 +03:00
|
|
|
|
2017-08-30 21:21:40 +03:00
|
|
|
spapr_clear_pending_events(spapr);
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
|
spapr: Locate RTAS and device-tree based on real RMA
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl, defined RTAS_MAX_ADDR]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-07-21 07:02:04 +04:00
|
|
|
/*
|
2021-03-31 05:51:23 +03:00
|
|
|
* We place the device tree just below either the top of the RMA,
|
2019-01-30 04:42:16 +03:00
|
|
|
* or just below 2GB, whichever is lower, so that it can be
|
spapr: Locate RTAS and device-tree based on real RMA
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl, defined RTAS_MAX_ADDR]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-07-21 07:02:04 +04:00
|
|
|
* processed with 32-bit real mode code if necessary
|
|
|
|
*/
|
2021-03-31 05:51:23 +03:00
|
|
|
fdt_addr = MIN(spapr->rma_size, FDT_MAX_ADDR) - FDT_MAX_SIZE;
|
spapr: Locate RTAS and device-tree based on real RMA
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl, defined RTAS_MAX_ADDR]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-07-21 07:02:04 +04:00
|
|
|
|
2019-10-18 13:25:49 +03:00
|
|
|
fdt = spapr_build_fdt(spapr, true, FDT_MAX_SIZE);
|
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 08:51:55 +03:00
|
|
|
if (spapr->vof) {
|
2021-07-08 09:56:25 +03:00
|
|
|
spapr_vof_reset(spapr, fdt, &error_fatal);
|
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 08:51:55 +03:00
|
|
|
/*
|
|
|
|
* Do not pack the FDT as the client may change properties.
|
|
|
|
* VOF client does not expect the FDT so we do not load it to the VM.
|
|
|
|
*/
|
|
|
|
} else {
|
|
|
|
rc = fdt_pack(fdt);
|
|
|
|
/* Should only fail if we've built a corrupted tree */
|
|
|
|
assert(rc == 0);
|
2016-10-25 03:51:33 +03:00
|
|
|
|
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 08:51:55 +03:00
|
|
|
spapr_cpu_set_entry_state(first_ppc_cpu, SPAPR_ENTRY_POINT,
|
|
|
|
0, fdt_addr, 0);
|
|
|
|
cpu_physical_memory_write(fdt_addr, fdt, fdt_totalsize(fdt));
|
|
|
|
}
|
2016-10-25 03:51:33 +03:00
|
|
|
qemu_fdt_dumpdtb(fdt, fdt_totalsize(fdt));
|
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 08:51:55 +03:00
|
|
|
|
2018-12-21 03:34:48 +03:00
|
|
|
g_free(spapr->fdt_blob);
|
|
|
|
spapr->fdt_size = fdt_totalsize(fdt);
|
|
|
|
spapr->fdt_initial_size = spapr->fdt_size;
|
|
|
|
spapr->fdt_blob = fdt;
|
2016-10-25 03:51:33 +03:00
|
|
|
|
2022-09-26 20:38:52 +03:00
|
|
|
/* Set machine->fdt for 'dumpdtb' QMP/HMP command */
|
|
|
|
machine->fdt = fdt;
|
|
|
|
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
/* Set up the entry state */
|
2013-05-30 00:29:20 +04:00
|
|
|
first_ppc_cpu->env.gpr[5] = 0;
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
|
2020-03-16 17:26:08 +03:00
|
|
|
spapr->fwnmi_system_reset_addr = -1;
|
2020-03-16 17:26:07 +03:00
|
|
|
spapr->fwnmi_machine_check_addr = -1;
|
|
|
|
spapr->fwnmi_machine_check_interlock = -1;
|
2020-01-30 21:44:19 +03:00
|
|
|
|
|
|
|
/* Signal all vCPUs waiting on this condition */
|
2020-03-16 17:26:07 +03:00
|
|
|
qemu_cond_broadcast(&spapr->fwnmi_machine_check_interlock_cond);
|
2020-01-30 21:44:22 +03:00
|
|
|
|
2023-10-18 16:03:36 +03:00
|
|
|
migrate_del_blocker(&spapr->fwnmi_migration_blocker);
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04: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 07:35:37 +03:00
|
|
|
static void spapr_create_nvram(SpaprMachineState *spapr)
|
2012-11-12 20:46:57 +04:00
|
|
|
{
|
qdev: Convert uses of qdev_create() with Coccinelle
This is the transformation explained in the commit before previous.
Takes care of just one pattern that needs conversion. More to come in
this series.
Coccinelle script:
@ depends on !(file in "hw/arm/highbank.c")@
expression bus, type_name, dev, expr;
@@
- dev = qdev_create(bus, type_name);
+ dev = qdev_new(type_name);
... when != dev = expr
- qdev_init_nofail(dev);
+ qdev_realize_and_unref(dev, bus, &error_fatal);
@@
expression bus, type_name, dev, expr;
identifier DOWN;
@@
- dev = DOWN(qdev_create(bus, type_name));
+ dev = DOWN(qdev_new(type_name));
... when != dev = expr
- qdev_init_nofail(DEVICE(dev));
+ qdev_realize_and_unref(DEVICE(dev), bus, &error_fatal);
@@
expression bus, type_name, expr;
identifier dev;
@@
- DeviceState *dev = qdev_create(bus, type_name);
+ DeviceState *dev = qdev_new(type_name);
... when != dev = expr
- qdev_init_nofail(dev);
+ qdev_realize_and_unref(dev, bus, &error_fatal);
@@
expression bus, type_name, dev, expr, errp;
symbol true;
@@
- dev = qdev_create(bus, type_name);
+ dev = qdev_new(type_name);
... when != dev = expr
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize_and_unref(dev, bus, errp);
@@
expression bus, type_name, expr, errp;
identifier dev;
symbol true;
@@
- DeviceState *dev = qdev_create(bus, type_name);
+ DeviceState *dev = qdev_new(type_name);
... when != dev = expr
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize_and_unref(dev, bus, errp);
The first rule exempts hw/arm/highbank.c, because it matches along two
control flow paths there, with different @type_name. Covered by the
next commit's manual conversions.
Missing #include "qapi/error.h" added manually.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-10-armbru@redhat.com>
[Conflicts in hw/misc/empty_slot.c and hw/sparc/leon3.c resolved]
2020-06-10 08:31:58 +03:00
|
|
|
DeviceState *dev = qdev_new("spapr-nvram");
|
2013-11-22 13:27:40 +04:00
|
|
|
DriveInfo *dinfo = drive_get(IF_PFLASH, 0, 0);
|
2012-11-12 20:46:57 +04:00
|
|
|
|
2013-11-22 13:27:40 +04:00
|
|
|
if (dinfo) {
|
qdev: Make qdev_prop_set_drive() match the other helpers
qdev_prop_set_drive() can fail. None of the other qdev_prop_set_FOO()
can; they abort on error.
To clean up this inconsistency, rename qdev_prop_set_drive() to
qdev_prop_set_drive_err(), and create a qdev_prop_set_drive() that
aborts on error.
Coccinelle script to update callers:
@ depends on !(file in "hw/core/qdev-properties-system.c")@
expression dev, name, value;
symbol error_abort;
@@
- qdev_prop_set_drive(dev, name, value, &error_abort);
+ qdev_prop_set_drive(dev, name, value);
@@
expression dev, name, value, errp;
@@
- qdev_prop_set_drive(dev, name, value, errp);
+ qdev_prop_set_drive_err(dev, name, value, errp);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200622094227.1271650-14-armbru@redhat.com>
2020-06-22 12:42:24 +03:00
|
|
|
qdev_prop_set_drive_err(dev, "drive", blk_by_legacy_dinfo(dinfo),
|
|
|
|
&error_fatal);
|
2012-11-12 20:46:57 +04:00
|
|
|
}
|
|
|
|
|
qdev: Convert uses of qdev_create() with Coccinelle
This is the transformation explained in the commit before previous.
Takes care of just one pattern that needs conversion. More to come in
this series.
Coccinelle script:
@ depends on !(file in "hw/arm/highbank.c")@
expression bus, type_name, dev, expr;
@@
- dev = qdev_create(bus, type_name);
+ dev = qdev_new(type_name);
... when != dev = expr
- qdev_init_nofail(dev);
+ qdev_realize_and_unref(dev, bus, &error_fatal);
@@
expression bus, type_name, dev, expr;
identifier DOWN;
@@
- dev = DOWN(qdev_create(bus, type_name));
+ dev = DOWN(qdev_new(type_name));
... when != dev = expr
- qdev_init_nofail(DEVICE(dev));
+ qdev_realize_and_unref(DEVICE(dev), bus, &error_fatal);
@@
expression bus, type_name, expr;
identifier dev;
@@
- DeviceState *dev = qdev_create(bus, type_name);
+ DeviceState *dev = qdev_new(type_name);
... when != dev = expr
- qdev_init_nofail(dev);
+ qdev_realize_and_unref(dev, bus, &error_fatal);
@@
expression bus, type_name, dev, expr, errp;
symbol true;
@@
- dev = qdev_create(bus, type_name);
+ dev = qdev_new(type_name);
... when != dev = expr
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize_and_unref(dev, bus, errp);
@@
expression bus, type_name, expr, errp;
identifier dev;
symbol true;
@@
- DeviceState *dev = qdev_create(bus, type_name);
+ DeviceState *dev = qdev_new(type_name);
... when != dev = expr
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize_and_unref(dev, bus, errp);
The first rule exempts hw/arm/highbank.c, because it matches along two
control flow paths there, with different @type_name. Covered by the
next commit's manual conversions.
Missing #include "qapi/error.h" added manually.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-10-armbru@redhat.com>
[Conflicts in hw/misc/empty_slot.c and hw/sparc/leon3.c resolved]
2020-06-10 08:31:58 +03:00
|
|
|
qdev_realize_and_unref(dev, &spapr->vio_bus->bus, &error_fatal);
|
2012-11-12 20:46:57 +04: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 07:35:37 +03:00
|
|
|
spapr->nvram = (struct SpaprNvram *)dev;
|
2012-11-12 20:46:57 +04: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 07:35:37 +03:00
|
|
|
static void spapr_rtc_create(SpaprMachineState *spapr)
|
2015-02-06 06:55:51 +03:00
|
|
|
{
|
qom: Less verbose object_initialize_child()
All users of object_initialize_child() pass the obvious child size
argument. Almost all pass &error_abort and no properties. Tiresome.
Rename object_initialize_child() to
object_initialize_child_with_props() to free the name. New
convenience wrapper object_initialize_child() automates the size
argument, and passes &error_abort and no properties.
Rename object_initialize_childv() to
object_initialize_child_with_propsv() for consistency.
Convert callers with this Coccinelle script:
@@
expression parent, propname, type;
expression child, size;
symbol error_abort;
@@
- object_initialize_child(parent, propname, OBJECT(child), size, type, &error_abort, NULL)
+ object_initialize_child(parent, propname, child, size, type, &error_abort, NULL)
@@
expression parent, propname, type;
expression child;
symbol error_abort;
@@
- object_initialize_child(parent, propname, child, sizeof(*child), type, &error_abort, NULL)
+ object_initialize_child(parent, propname, child, type)
@@
expression parent, propname, type;
expression child;
symbol error_abort;
@@
- object_initialize_child(parent, propname, &child, sizeof(child), type, &error_abort, NULL)
+ object_initialize_child(parent, propname, &child, type)
@@
expression parent, propname, type;
expression child, size, err;
expression list props;
@@
- object_initialize_child(parent, propname, child, size, type, err, props)
+ object_initialize_child_with_props(parent, propname, child, size, type, err, props)
Note that Coccinelle chokes on ARMSSE typedef vs. macro in
hw/arm/armsse.c. Worked around by temporarily renaming the macro for
the spatch run.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
[Rebased: machine opentitan is new (commit fe0fe4735e7)]
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-37-armbru@redhat.com>
2020-06-10 08:32:25 +03:00
|
|
|
object_initialize_child_with_props(OBJECT(spapr), "rtc", &spapr->rtc,
|
|
|
|
sizeof(spapr->rtc), TYPE_SPAPR_RTC,
|
|
|
|
&error_fatal, NULL);
|
qdev: Convert bus-less devices to qdev_realize() with Coccinelle
All remaining conversions to qdev_realize() are for bus-less devices.
Coccinelle script:
// only correct for bus-less @dev!
@@
expression errp;
expression dev;
@@
- qdev_init_nofail(dev);
+ qdev_realize(dev, NULL, &error_fatal);
@ depends on !(file in "hw/core/qdev.c") && !(file in "hw/core/bus.c")@
expression errp;
expression dev;
symbol true;
@@
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize(DEVICE(dev), NULL, errp);
@ depends on !(file in "hw/core/qdev.c") && !(file in "hw/core/bus.c")@
expression errp;
expression dev;
symbol true;
@@
- object_property_set_bool(dev, true, "realized", errp);
+ qdev_realize(DEVICE(dev), NULL, errp);
Note that Coccinelle chokes on ARMSSE typedef vs. macro in
hw/arm/armsse.c. Worked around by temporarily renaming the macro for
the spatch run.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-57-armbru@redhat.com>
2020-06-10 08:32:45 +03:00
|
|
|
qdev_realize(DEVICE(&spapr->rtc), NULL, &error_fatal);
|
2017-03-07 12:23:40 +03:00
|
|
|
object_property_add_alias(OBJECT(spapr), "rtc-time", OBJECT(&spapr->rtc),
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
"date");
|
2015-02-06 06:55:51 +03:00
|
|
|
}
|
|
|
|
|
2012-08-14 15:11:49 +04:00
|
|
|
/* Returns whether we want to use VGA or not */
|
2016-01-20 04:58:39 +03:00
|
|
|
static bool spapr_vga_init(PCIBus *pci_bus, Error **errp)
|
2012-08-06 20:42:00 +04:00
|
|
|
{
|
2022-05-01 15:25:05 +03:00
|
|
|
vga_interface_created = true;
|
2012-08-14 15:11:49 +04:00
|
|
|
switch (vga_interface_type) {
|
|
|
|
case VGA_NONE:
|
2014-03-10 18:37:41 +04:00
|
|
|
return false;
|
|
|
|
case VGA_DEVICE:
|
|
|
|
return true;
|
2012-09-08 14:40:45 +04:00
|
|
|
case VGA_STD:
|
2015-09-15 08:51:29 +03:00
|
|
|
case VGA_VIRTIO:
|
2019-01-30 16:36:39 +03:00
|
|
|
case VGA_CIRRUS:
|
2012-09-08 14:40:45 +04:00
|
|
|
return pci_vga_init(pci_bus) != NULL;
|
2012-08-14 15:11:49 +04:00
|
|
|
default:
|
2016-01-20 04:58:39 +03:00
|
|
|
error_setg(errp,
|
|
|
|
"Unsupported VGA mode, only -vga std or -vga virtio is supported");
|
|
|
|
return false;
|
2012-08-06 20:42:00 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
static int spapr_pre_load(void *opaque)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = spapr_caps_pre_load(opaque);
|
|
|
|
if (rc) {
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-02-06 06:55:52 +03:00
|
|
|
static int spapr_post_load(void *opaque, int version_id)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = (SpaprMachineState *)opaque;
|
2015-02-06 06:55:52 +03:00
|
|
|
int err = 0;
|
|
|
|
|
2017-12-11 07:09:37 +03:00
|
|
|
err = spapr_caps_post_migration(spapr);
|
|
|
|
if (err) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-01-04 16:30:50 +03:00
|
|
|
/*
|
|
|
|
* In earlier versions, there was no separate qdev for the PAPR
|
2015-02-06 06:55:52 +03:00
|
|
|
* RTC, so the RTC offset was stored directly in sPAPREnvironment.
|
|
|
|
* So when migrating from those versions, poke the incoming offset
|
2019-01-04 16:30:50 +03:00
|
|
|
* value into the RTC device
|
|
|
|
*/
|
2015-02-06 06:55:52 +03:00
|
|
|
if (version_id < 3) {
|
2017-03-07 12:23:40 +03:00
|
|
|
err = spapr_rtc_import_offset(&spapr->rtc, spapr->rtc_offset);
|
2019-01-04 16:30:50 +03:00
|
|
|
if (err) {
|
|
|
|
return err;
|
|
|
|
}
|
2015-02-06 06:55:52 +03:00
|
|
|
}
|
|
|
|
|
2017-11-28 20:43:10 +03:00
|
|
|
if (kvm_enabled() && spapr->patb_entry) {
|
2017-06-12 08:32:35 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
|
2019-02-15 20:00:27 +03:00
|
|
|
bool radix = !!(spapr->patb_entry & PATE1_GR);
|
2017-06-12 08:32:35 +03:00
|
|
|
bool gtse = !!(cpu->env.spr[SPR_LPCR] & LPCR_GTSE);
|
2019-02-15 20:00:18 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Update LPCR:HR and UPRT as they may not be set properly in
|
|
|
|
* the stream
|
|
|
|
*/
|
|
|
|
spapr_set_all_lpcrs(radix ? (LPCR_HR | LPCR_UPRT) : 0,
|
|
|
|
LPCR_HR | LPCR_UPRT);
|
2017-06-12 08:32:35 +03:00
|
|
|
|
|
|
|
err = kvmppc_configure_v3_mmu(cpu, radix, gtse, spapr->patb_entry);
|
|
|
|
if (err) {
|
|
|
|
error_report("Process table config unsupported by the host");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-12 01:38:16 +03:00
|
|
|
err = spapr_irq_post_load(spapr, version_id);
|
|
|
|
if (err) {
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2015-02-06 06:55:52 +03:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
static int spapr_pre_save(void *opaque)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = spapr_caps_pre_save(opaque);
|
|
|
|
if (rc) {
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-02-06 06:55:52 +03:00
|
|
|
static bool version_before_3(void *opaque, int version_id)
|
|
|
|
{
|
|
|
|
return version_id < 3;
|
|
|
|
}
|
|
|
|
|
2017-07-11 21:07:55 +03:00
|
|
|
static bool spapr_pending_events_needed(void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = (SpaprMachineState *)opaque;
|
2017-07-11 21:07:55 +03:00
|
|
|
return !QTAILQ_EMPTY(&spapr->pending_events);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_spapr_event_entry = {
|
|
|
|
.name = "spapr_event_log_entry",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
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 07:35:37 +03:00
|
|
|
VMSTATE_UINT32(summary, SpaprEventLogEntry),
|
|
|
|
VMSTATE_UINT32(extended_length, SpaprEventLogEntry),
|
|
|
|
VMSTATE_VBUFFER_ALLOC_UINT32(extended_log, SpaprEventLogEntry, 0,
|
2017-07-12 04:55:53 +03:00
|
|
|
NULL, extended_length),
|
2017-07-11 21:07:55 +03:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_spapr_pending_events = {
|
|
|
|
.name = "spapr_pending_events",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_pending_events_needed,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
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 07:35:37 +03:00
|
|
|
VMSTATE_QTAILQ_V(pending_events, SpaprMachineState, 1,
|
|
|
|
vmstate_spapr_event_entry, SpaprEventLogEntry, next),
|
2017-07-11 21:07:55 +03:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2016-11-18 04:40:27 +03:00
|
|
|
static bool spapr_ov5_cas_needed(void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
|
|
|
SpaprOptionVector *ov5_mask = spapr_ovec_new();
|
2016-11-18 04:40:27 +03:00
|
|
|
bool cas_needed;
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
/* Prior to the introduction of SpaprOptionVector, we had two option
|
2016-11-18 04:40:27 +03:00
|
|
|
* vectors we dealt with: OV5_FORM1_AFFINITY, and OV5_DRCONF_MEMORY.
|
|
|
|
* Both of these options encode machine topology into the device-tree
|
|
|
|
* in such a way that the now-booted OS should still be able to interact
|
|
|
|
* appropriately with QEMU regardless of what options were actually
|
|
|
|
* negotiatied on the source side.
|
|
|
|
*
|
|
|
|
* As such, we can avoid migrating the CAS-negotiated options if these
|
|
|
|
* are the only options available on the current machine/platform.
|
|
|
|
* Since these are the only options available for pseries-2.7 and
|
|
|
|
* earlier, this allows us to maintain old->new/new->old migration
|
|
|
|
* compatibility.
|
|
|
|
*
|
|
|
|
* For QEMU 2.8+, there are additional CAS-negotiatable options available
|
|
|
|
* via default pseries-2.8 machines and explicit command-line parameters.
|
|
|
|
* Some of these options, like OV5_HP_EVT, *do* require QEMU to be aware
|
|
|
|
* of the actual CAS-negotiated values to continue working properly. For
|
|
|
|
* example, availability of memory unplug depends on knowing whether
|
|
|
|
* OV5_HP_EVT was negotiated via CAS.
|
|
|
|
*
|
|
|
|
* Thus, for any cases where the set of available CAS-negotiatable
|
|
|
|
* options extends beyond OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY, we
|
2018-05-04 00:16:48 +03:00
|
|
|
* include the CAS-negotiated options in the migration stream, unless
|
|
|
|
* if they affect boot time behaviour only.
|
2016-11-18 04:40:27 +03:00
|
|
|
*/
|
|
|
|
spapr_ovec_set(ov5_mask, OV5_FORM1_AFFINITY);
|
|
|
|
spapr_ovec_set(ov5_mask, OV5_DRCONF_MEMORY);
|
2018-05-04 00:16:48 +03:00
|
|
|
spapr_ovec_set(ov5_mask, OV5_DRMEM_V2);
|
2016-11-18 04:40:27 +03:00
|
|
|
|
2019-11-29 08:23:21 +03:00
|
|
|
/* We need extra information if we have any bits outside the mask
|
|
|
|
* defined above */
|
|
|
|
cas_needed = !spapr_ovec_subset(spapr->ov5, ov5_mask);
|
2016-11-18 04:40:27 +03:00
|
|
|
|
|
|
|
spapr_ovec_cleanup(ov5_mask);
|
|
|
|
|
|
|
|
return cas_needed;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_spapr_ov5_cas = {
|
|
|
|
.name = "spapr_option_vector_ov5_cas",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_ov5_cas_needed,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
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 07:35:37 +03:00
|
|
|
VMSTATE_STRUCT_POINTER_V(ov5_cas, SpaprMachineState, 1,
|
|
|
|
vmstate_spapr_ovec, SpaprOptionVector),
|
2016-11-18 04:40:27 +03:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2017-03-01 09:54:36 +03:00
|
|
|
static bool spapr_patb_entry_needed(void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2017-03-01 09:54:36 +03:00
|
|
|
|
|
|
|
return !!spapr->patb_entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_spapr_patb_entry = {
|
|
|
|
.name = "spapr_patb_entry",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_patb_entry_needed,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
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 07:35:37 +03:00
|
|
|
VMSTATE_UINT64(patb_entry, SpaprMachineState),
|
2017-03-01 09:54:36 +03:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2018-07-30 17:11:32 +03:00
|
|
|
static bool spapr_irq_map_needed(void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2018-07-30 17:11:32 +03:00
|
|
|
|
|
|
|
return spapr->irq_map && !bitmap_empty(spapr->irq_map, spapr->irq_map_nr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_spapr_irq_map = {
|
|
|
|
.name = "spapr_irq_map",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_irq_map_needed,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
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 07:35:37 +03:00
|
|
|
VMSTATE_BITMAP(irq_map, SpaprMachineState, 0, irq_map_nr),
|
2018-07-30 17:11:32 +03:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2018-12-21 03:34:48 +03:00
|
|
|
static bool spapr_dtb_needed(void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(opaque);
|
2018-12-21 03:34:48 +03:00
|
|
|
|
|
|
|
return smc->update_dt_enabled;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int spapr_dtb_pre_load(void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = (SpaprMachineState *)opaque;
|
2018-12-21 03:34:48 +03:00
|
|
|
|
|
|
|
g_free(spapr->fdt_blob);
|
|
|
|
spapr->fdt_blob = NULL;
|
|
|
|
spapr->fdt_size = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const VMStateDescription vmstate_spapr_dtb = {
|
|
|
|
.name = "spapr_dtb",
|
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_dtb_needed,
|
|
|
|
.pre_load = spapr_dtb_pre_load,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
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 07:35:37 +03:00
|
|
|
VMSTATE_UINT32(fdt_initial_size, SpaprMachineState),
|
|
|
|
VMSTATE_UINT32(fdt_size, SpaprMachineState),
|
|
|
|
VMSTATE_VBUFFER_ALLOC_UINT32(fdt_blob, SpaprMachineState, 0, NULL,
|
2018-12-21 03:34:48 +03:00
|
|
|
fdt_size),
|
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2020-01-30 21:44:22 +03:00
|
|
|
static bool spapr_fwnmi_needed(void *opaque)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = (SpaprMachineState *)opaque;
|
|
|
|
|
2020-03-16 17:26:07 +03:00
|
|
|
return spapr->fwnmi_machine_check_addr != -1;
|
2020-01-30 21:44:22 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int spapr_fwnmi_pre_save(void *opaque)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = (SpaprMachineState *)opaque;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if machine check handling is in progress and print a
|
|
|
|
* warning message.
|
|
|
|
*/
|
2020-03-16 17:26:07 +03:00
|
|
|
if (spapr->fwnmi_machine_check_interlock != -1) {
|
2020-01-30 21:44:22 +03:00
|
|
|
warn_report("A machine check is being handled during migration. The"
|
|
|
|
"handler may run and log hardware error on the destination");
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-16 17:26:07 +03:00
|
|
|
static const VMStateDescription vmstate_spapr_fwnmi = {
|
|
|
|
.name = "spapr_fwnmi",
|
2020-01-30 21:44:22 +03:00
|
|
|
.version_id = 1,
|
|
|
|
.minimum_version_id = 1,
|
|
|
|
.needed = spapr_fwnmi_needed,
|
|
|
|
.pre_save = spapr_fwnmi_pre_save,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
2020-03-16 17:26:08 +03:00
|
|
|
VMSTATE_UINT64(fwnmi_system_reset_addr, SpaprMachineState),
|
2020-03-16 17:26:07 +03:00
|
|
|
VMSTATE_UINT64(fwnmi_machine_check_addr, SpaprMachineState),
|
|
|
|
VMSTATE_INT32(fwnmi_machine_check_interlock, SpaprMachineState),
|
2020-01-30 21:44:22 +03:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
static const VMStateDescription vmstate_spapr = {
|
|
|
|
.name = "spapr",
|
2015-02-06 06:55:52 +03:00
|
|
|
.version_id = 3,
|
2013-07-18 23:33:01 +04:00
|
|
|
.minimum_version_id = 1,
|
2018-01-12 08:33:43 +03:00
|
|
|
.pre_load = spapr_pre_load,
|
2015-02-06 06:55:52 +03:00
|
|
|
.post_load = spapr_post_load,
|
2018-01-12 08:33:43 +03:00
|
|
|
.pre_save = spapr_pre_save,
|
2023-12-21 06:16:28 +03:00
|
|
|
.fields = (const VMStateField[]) {
|
2015-02-06 06:55:52 +03:00
|
|
|
/* used to be @next_irq */
|
|
|
|
VMSTATE_UNUSED_BUFFER(version_before_3, 0, 4),
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
/* RTC offset */
|
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 07:35:37 +03:00
|
|
|
VMSTATE_UINT64_TEST(rtc_offset, SpaprMachineState, version_before_3),
|
2015-02-06 06:55:52 +03: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 07:35:37 +03:00
|
|
|
VMSTATE_PPC_TIMEBASE_V(tb, SpaprMachineState, 2),
|
2013-07-18 23:33:01 +04:00
|
|
|
VMSTATE_END_OF_LIST()
|
|
|
|
},
|
2023-12-21 06:16:28 +03:00
|
|
|
.subsections = (const VMStateDescription * const []) {
|
2016-11-18 04:40:27 +03:00
|
|
|
&vmstate_spapr_ov5_cas,
|
2017-03-01 09:54:36 +03:00
|
|
|
&vmstate_spapr_patb_entry,
|
2017-07-11 21:07:55 +03:00
|
|
|
&vmstate_spapr_pending_events,
|
2018-01-12 08:33:43 +03:00
|
|
|
&vmstate_spapr_cap_htm,
|
|
|
|
&vmstate_spapr_cap_vsx,
|
|
|
|
&vmstate_spapr_cap_dfp,
|
2018-01-19 08:00:02 +03:00
|
|
|
&vmstate_spapr_cap_cfpc,
|
2018-01-19 08:00:03 +03:00
|
|
|
&vmstate_spapr_cap_sbbc,
|
2018-01-19 08:00:04 +03:00
|
|
|
&vmstate_spapr_cap_ibs,
|
2019-05-17 07:10:44 +03:00
|
|
|
&vmstate_spapr_cap_hpt_maxpagesize,
|
2018-07-30 17:11:32 +03:00
|
|
|
&vmstate_spapr_irq_map,
|
2018-10-08 06:25:39 +03:00
|
|
|
&vmstate_spapr_cap_nested_kvm_hv,
|
2018-12-21 03:34:48 +03:00
|
|
|
&vmstate_spapr_dtb,
|
2019-03-01 05:43:14 +03:00
|
|
|
&vmstate_spapr_cap_large_decr,
|
2019-03-01 06:19:12 +03:00
|
|
|
&vmstate_spapr_cap_ccf_assist,
|
2020-01-30 21:44:18 +03:00
|
|
|
&vmstate_spapr_cap_fwnmi,
|
2020-03-16 17:26:07 +03:00
|
|
|
&vmstate_spapr_fwnmi,
|
2021-07-06 14:24:40 +03:00
|
|
|
&vmstate_spapr_cap_rpt_invalidate,
|
2016-11-18 04:40:27 +03:00
|
|
|
NULL
|
|
|
|
}
|
2013-07-18 23:33:01 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static int htab_save_setup(QEMUFile *f, void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
/* "Iteration" header */
|
2017-06-12 08:32:34 +03:00
|
|
|
if (!spapr->htab_shift) {
|
|
|
|
qemu_put_be32(f, -1);
|
|
|
|
} else {
|
|
|
|
qemu_put_be32(f, spapr->htab_shift);
|
|
|
|
}
|
2013-07-18 23:33:01 +04:00
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if (spapr->htab) {
|
|
|
|
spapr->htab_save_index = 0;
|
|
|
|
spapr->htab_first_pass = true;
|
|
|
|
} else {
|
2017-06-12 08:32:34 +03:00
|
|
|
if (spapr->htab_shift) {
|
|
|
|
assert(kvm_enabled());
|
|
|
|
}
|
2013-07-18 23:33:03 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
static void htab_save_chunk(QEMUFile *f, SpaprMachineState *spapr,
|
2017-09-19 17:11:07 +03:00
|
|
|
int chunkstart, int n_valid, int n_invalid)
|
|
|
|
{
|
|
|
|
qemu_put_be32(f, chunkstart);
|
|
|
|
qemu_put_be16(f, n_valid);
|
|
|
|
qemu_put_be16(f, n_invalid);
|
|
|
|
qemu_put_buffer(f, HPTE(spapr->htab, chunkstart),
|
|
|
|
HASH_PTE_SIZE_64 * n_valid);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void htab_save_end_marker(QEMUFile *f)
|
|
|
|
{
|
|
|
|
qemu_put_be32(f, 0);
|
|
|
|
qemu_put_be16(f, 0);
|
|
|
|
qemu_put_be16(f, 0);
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
static void htab_save_first_pass(QEMUFile *f, SpaprMachineState *spapr,
|
2013-07-18 23:33:01 +04:00
|
|
|
int64_t max_ns)
|
|
|
|
{
|
2016-02-11 03:40:44 +03:00
|
|
|
bool has_timeout = max_ns != -1;
|
2013-07-18 23:33:01 +04:00
|
|
|
int htabslots = HTAB_SIZE(spapr) / HASH_PTE_SIZE_64;
|
|
|
|
int index = spapr->htab_save_index;
|
2013-08-21 19:03:08 +04:00
|
|
|
int64_t starttime = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
assert(spapr->htab_first_pass);
|
|
|
|
|
|
|
|
do {
|
|
|
|
int chunkstart;
|
|
|
|
|
|
|
|
/* Consume invalid HPTEs */
|
|
|
|
while ((index < htabslots)
|
|
|
|
&& !HPTE_VALID(HPTE(spapr->htab, index))) {
|
|
|
|
CLEAN_HPTE(HPTE(spapr->htab, index));
|
2017-03-23 13:04:55 +03:00
|
|
|
index++;
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Consume valid HPTEs */
|
|
|
|
chunkstart = index;
|
2014-11-17 07:12:29 +03:00
|
|
|
while ((index < htabslots) && (index - chunkstart < USHRT_MAX)
|
2013-07-18 23:33:01 +04:00
|
|
|
&& HPTE_VALID(HPTE(spapr->htab, index))) {
|
|
|
|
CLEAN_HPTE(HPTE(spapr->htab, index));
|
2017-03-23 13:04:55 +03:00
|
|
|
index++;
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (index > chunkstart) {
|
|
|
|
int n_valid = index - chunkstart;
|
|
|
|
|
2017-09-19 17:11:07 +03:00
|
|
|
htab_save_chunk(f, spapr, chunkstart, n_valid, 0);
|
2013-07-18 23:33:01 +04:00
|
|
|
|
2016-02-11 03:40:44 +03:00
|
|
|
if (has_timeout &&
|
|
|
|
(qemu_clock_get_ns(QEMU_CLOCK_REALTIME) - starttime) > max_ns) {
|
2013-07-18 23:33:01 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2023-05-15 22:56:58 +03:00
|
|
|
} while ((index < htabslots) && !migration_rate_exceeded(f));
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
if (index >= htabslots) {
|
|
|
|
assert(index == htabslots);
|
|
|
|
index = 0;
|
|
|
|
spapr->htab_first_pass = false;
|
|
|
|
}
|
|
|
|
spapr->htab_save_index = index;
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
static int htab_save_later_pass(QEMUFile *f, SpaprMachineState *spapr,
|
2013-07-18 23:33:03 +04:00
|
|
|
int64_t max_ns)
|
2013-07-18 23:33:01 +04:00
|
|
|
{
|
|
|
|
bool final = max_ns < 0;
|
|
|
|
int htabslots = HTAB_SIZE(spapr) / HASH_PTE_SIZE_64;
|
|
|
|
int examined = 0, sent = 0;
|
|
|
|
int index = spapr->htab_save_index;
|
2013-08-21 19:03:08 +04:00
|
|
|
int64_t starttime = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
assert(!spapr->htab_first_pass);
|
|
|
|
|
|
|
|
do {
|
|
|
|
int chunkstart, invalidstart;
|
|
|
|
|
|
|
|
/* Consume non-dirty HPTEs */
|
|
|
|
while ((index < htabslots)
|
|
|
|
&& !HPTE_DIRTY(HPTE(spapr->htab, index))) {
|
|
|
|
index++;
|
|
|
|
examined++;
|
|
|
|
}
|
|
|
|
|
|
|
|
chunkstart = index;
|
|
|
|
/* Consume valid dirty HPTEs */
|
2014-11-17 07:12:29 +03:00
|
|
|
while ((index < htabslots) && (index - chunkstart < USHRT_MAX)
|
2013-07-18 23:33:01 +04:00
|
|
|
&& HPTE_DIRTY(HPTE(spapr->htab, index))
|
|
|
|
&& HPTE_VALID(HPTE(spapr->htab, index))) {
|
|
|
|
CLEAN_HPTE(HPTE(spapr->htab, index));
|
|
|
|
index++;
|
|
|
|
examined++;
|
|
|
|
}
|
|
|
|
|
|
|
|
invalidstart = index;
|
|
|
|
/* Consume invalid dirty HPTEs */
|
2014-11-17 07:12:29 +03:00
|
|
|
while ((index < htabslots) && (index - invalidstart < USHRT_MAX)
|
2013-07-18 23:33:01 +04:00
|
|
|
&& HPTE_DIRTY(HPTE(spapr->htab, index))
|
|
|
|
&& !HPTE_VALID(HPTE(spapr->htab, index))) {
|
|
|
|
CLEAN_HPTE(HPTE(spapr->htab, index));
|
|
|
|
index++;
|
|
|
|
examined++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (index > chunkstart) {
|
|
|
|
int n_valid = invalidstart - chunkstart;
|
|
|
|
int n_invalid = index - invalidstart;
|
|
|
|
|
2017-09-19 17:11:07 +03:00
|
|
|
htab_save_chunk(f, spapr, chunkstart, n_valid, n_invalid);
|
2013-07-18 23:33:01 +04:00
|
|
|
sent += index - chunkstart;
|
|
|
|
|
2013-08-21 19:03:08 +04:00
|
|
|
if (!final && (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) - starttime) > max_ns) {
|
2013-07-18 23:33:01 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (examined >= htabslots) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (index >= htabslots) {
|
|
|
|
assert(index == htabslots);
|
|
|
|
index = 0;
|
|
|
|
}
|
2023-05-15 22:56:58 +03:00
|
|
|
} while ((examined < htabslots) && (!migration_rate_exceeded(f) || final));
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
if (index >= htabslots) {
|
|
|
|
assert(index == htabslots);
|
|
|
|
index = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
spapr->htab_save_index = index;
|
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
return (examined >= htabslots) && (sent == 0) ? 1 : 0;
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
#define MAX_ITERATION_NS 5000000 /* 5 ms */
|
|
|
|
#define MAX_KVM_BUF_SIZE 2048
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
static int htab_save_iterate(QEMUFile *f, void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2016-02-09 02:28:58 +03:00
|
|
|
int fd;
|
2013-07-18 23:33:03 +04:00
|
|
|
int rc = 0;
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
/* Iteration header */
|
2017-06-12 08:32:34 +03:00
|
|
|
if (!spapr->htab_shift) {
|
|
|
|
qemu_put_be32(f, -1);
|
2017-07-18 13:16:32 +03:00
|
|
|
return 1;
|
2017-06-12 08:32:34 +03:00
|
|
|
} else {
|
|
|
|
qemu_put_be32(f, 0);
|
|
|
|
}
|
2013-07-18 23:33:01 +04:00
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if (!spapr->htab) {
|
|
|
|
assert(kvm_enabled());
|
|
|
|
|
2016-02-09 02:28:58 +03:00
|
|
|
fd = get_htab_fd(spapr);
|
|
|
|
if (fd < 0) {
|
|
|
|
return fd;
|
2014-11-17 07:12:28 +03:00
|
|
|
}
|
|
|
|
|
2016-02-09 02:28:58 +03:00
|
|
|
rc = kvmppc_save_htab(f, fd, MAX_KVM_BUF_SIZE, MAX_ITERATION_NS);
|
2013-07-18 23:33:03 +04:00
|
|
|
if (rc < 0) {
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
} else if (spapr->htab_first_pass) {
|
2013-07-18 23:33:01 +04:00
|
|
|
htab_save_first_pass(f, spapr, MAX_ITERATION_NS);
|
|
|
|
} else {
|
2013-07-18 23:33:03 +04:00
|
|
|
rc = htab_save_later_pass(f, spapr, MAX_ITERATION_NS);
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
|
2017-09-19 17:11:07 +03:00
|
|
|
htab_save_end_marker(f);
|
2013-07-18 23:33:01 +04:00
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
return rc;
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int htab_save_complete(QEMUFile *f, void *opaque)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2016-02-09 02:28:58 +03:00
|
|
|
int fd;
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
/* Iteration header */
|
2017-06-12 08:32:34 +03:00
|
|
|
if (!spapr->htab_shift) {
|
|
|
|
qemu_put_be32(f, -1);
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
qemu_put_be32(f, 0);
|
|
|
|
}
|
2013-07-18 23:33:01 +04:00
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if (!spapr->htab) {
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
assert(kvm_enabled());
|
|
|
|
|
2016-02-09 02:28:58 +03:00
|
|
|
fd = get_htab_fd(spapr);
|
|
|
|
if (fd < 0) {
|
|
|
|
return fd;
|
2014-11-17 07:12:28 +03:00
|
|
|
}
|
|
|
|
|
2016-02-09 02:28:58 +03:00
|
|
|
rc = kvmppc_save_htab(f, fd, MAX_KVM_BUF_SIZE, -1);
|
2013-07-18 23:33:03 +04:00
|
|
|
if (rc < 0) {
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
} else {
|
2016-02-11 03:40:44 +03:00
|
|
|
if (spapr->htab_first_pass) {
|
|
|
|
htab_save_first_pass(f, spapr, -1);
|
|
|
|
}
|
2013-07-18 23:33:03 +04:00
|
|
|
htab_save_later_pass(f, spapr, -1);
|
|
|
|
}
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
/* End marker */
|
2017-09-19 17:11:07 +03:00
|
|
|
htab_save_end_marker(f);
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int htab_load(QEMUFile *f, void *opaque, int version_id)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2013-07-18 23:33:01 +04:00
|
|
|
uint32_t section_hdr;
|
2013-07-18 23:33:03 +04:00
|
|
|
int fd = -1;
|
2017-09-15 16:16:20 +03:00
|
|
|
Error *local_err = NULL;
|
2013-07-18 23:33:01 +04:00
|
|
|
|
|
|
|
if (version_id < 1 || version_id > 1) {
|
2016-01-20 04:59:05 +03:00
|
|
|
error_report("htab_load() bad version");
|
2013-07-18 23:33:01 +04:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
section_hdr = qemu_get_be32(f);
|
|
|
|
|
2017-06-12 08:32:34 +03:00
|
|
|
if (section_hdr == -1) {
|
|
|
|
spapr_free_hpt(spapr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
if (section_hdr) {
|
2020-10-26 15:40:54 +03:00
|
|
|
int ret;
|
|
|
|
|
2016-02-09 03:21:56 +03:00
|
|
|
/* First section gives the htab size */
|
2020-10-26 15:40:54 +03:00
|
|
|
ret = spapr_reallocate_hpt(spapr, section_hdr, &local_err);
|
|
|
|
if (ret < 0) {
|
2016-02-09 03:21:56 +03:00
|
|
|
error_report_err(local_err);
|
2020-10-26 15:40:54 +03:00
|
|
|
return ret;
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if (!spapr->htab) {
|
|
|
|
assert(kvm_enabled());
|
|
|
|
|
2017-09-15 16:16:20 +03:00
|
|
|
fd = kvmppc_get_htab_fd(true, 0, &local_err);
|
2013-07-18 23:33:03 +04:00
|
|
|
if (fd < 0) {
|
2017-09-15 16:16:20 +03:00
|
|
|
error_report_err(local_err);
|
2017-09-15 16:16:10 +03:00
|
|
|
return fd;
|
2013-07-18 23:33:03 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
while (true) {
|
|
|
|
uint32_t index;
|
|
|
|
uint16_t n_valid, n_invalid;
|
|
|
|
|
|
|
|
index = qemu_get_be32(f);
|
|
|
|
n_valid = qemu_get_be16(f);
|
|
|
|
n_invalid = qemu_get_be16(f);
|
|
|
|
|
|
|
|
if ((index == 0) && (n_valid == 0) && (n_invalid == 0)) {
|
|
|
|
/* End of Stream */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if ((index + n_valid + n_invalid) >
|
2013-07-18 23:33:01 +04:00
|
|
|
(HTAB_SIZE(spapr) / HASH_PTE_SIZE_64)) {
|
|
|
|
/* Bad index in stream */
|
2016-01-20 04:59:05 +03:00
|
|
|
error_report(
|
|
|
|
"htab_load() bad index %d (%hd+%hd entries) in htab stream (htab_shift=%d)",
|
|
|
|
index, n_valid, n_invalid, spapr->htab_shift);
|
2013-07-18 23:33:01 +04:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if (spapr->htab) {
|
|
|
|
if (n_valid) {
|
|
|
|
qemu_get_buffer(f, HPTE(spapr->htab, index),
|
|
|
|
HASH_PTE_SIZE_64 * n_valid);
|
|
|
|
}
|
|
|
|
if (n_invalid) {
|
|
|
|
memset(HPTE(spapr->htab, index + n_valid), 0,
|
|
|
|
HASH_PTE_SIZE_64 * n_invalid);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
assert(fd >= 0);
|
|
|
|
|
2020-10-26 15:40:47 +03:00
|
|
|
rc = kvmppc_load_htab_chunk(f, fd, index, n_valid, n_invalid,
|
|
|
|
&local_err);
|
2013-07-18 23:33:03 +04:00
|
|
|
if (rc < 0) {
|
2020-10-26 15:40:47 +03:00
|
|
|
error_report_err(local_err);
|
2013-07-18 23:33:03 +04:00
|
|
|
return rc;
|
|
|
|
}
|
2013-07-18 23:33:01 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:03 +04:00
|
|
|
if (!spapr->htab) {
|
|
|
|
assert(fd >= 0);
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-06-28 12:52:25 +03:00
|
|
|
static void htab_save_cleanup(void *opaque)
|
2016-07-21 12:21:34 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = opaque;
|
2016-07-21 12:21:34 +03:00
|
|
|
|
|
|
|
close_htab_fd(spapr);
|
|
|
|
}
|
|
|
|
|
2013-07-18 23:33:01 +04:00
|
|
|
static SaveVMHandlers savevm_htab_handlers = {
|
2017-06-28 12:52:24 +03:00
|
|
|
.save_setup = htab_save_setup,
|
2013-07-18 23:33:01 +04:00
|
|
|
.save_live_iterate = htab_save_iterate,
|
2015-11-05 21:10:41 +03:00
|
|
|
.save_live_complete_precopy = htab_save_complete,
|
2017-06-28 12:52:25 +03:00
|
|
|
.save_cleanup = htab_save_cleanup,
|
2013-07-18 23:33:01 +04:00
|
|
|
.load_state = htab_load,
|
|
|
|
};
|
|
|
|
|
2015-03-18 15:30:44 +03:00
|
|
|
static void spapr_boot_set(void *opaque, const char *boot_device,
|
|
|
|
Error **errp)
|
|
|
|
{
|
2021-05-21 19:07:35 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(opaque);
|
|
|
|
|
|
|
|
g_free(spapr->boot_device);
|
|
|
|
spapr->boot_device = g_strdup(boot_device);
|
2015-03-18 15:30:44 +03: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 07:35:37 +03:00
|
|
|
static void spapr_create_lmb_dr_connectors(SpaprMachineState *spapr)
|
2015-08-12 06:16:48 +03:00
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
|
|
|
uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
|
2015-08-03 08:35:41 +03:00
|
|
|
uint32_t nr_lmbs = (machine->maxram_size - machine->ram_size)/lmb_size;
|
2015-08-12 06:16:48 +03:00
|
|
|
int i;
|
|
|
|
|
2023-06-23 15:45:47 +03:00
|
|
|
g_assert(!nr_lmbs || machine->device_memory);
|
2015-08-12 06:16:48 +03:00
|
|
|
for (i = 0; i < nr_lmbs; i++) {
|
|
|
|
uint64_t addr;
|
|
|
|
|
2018-04-23 19:51:17 +03:00
|
|
|
addr = i * lmb_size + machine->device_memory->base;
|
2017-06-08 15:18:34 +03:00
|
|
|
spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr / lmb_size);
|
2015-08-12 06:16:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If RAM size, maxmem size and individual node mem sizes aren't aligned
|
|
|
|
* to SPAPR_MEMORY_BLOCK_SIZE(256MB), then refuse to start the guest
|
|
|
|
* since we can't support such unaligned sizes with DRCONF_MEMORY.
|
|
|
|
*/
|
2016-01-25 14:46:47 +03:00
|
|
|
static void spapr_validate_node_memory(MachineState *machine, Error **errp)
|
2015-08-12 06:16:48 +03:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2016-01-25 14:46:47 +03:00
|
|
|
if (machine->ram_size % SPAPR_MEMORY_BLOCK_SIZE) {
|
|
|
|
error_setg(errp, "Memory size 0x" RAM_ADDR_FMT
|
2018-06-25 15:42:24 +03:00
|
|
|
" is not aligned to %" PRIu64 " MiB",
|
2016-01-25 14:46:47 +03:00
|
|
|
machine->ram_size,
|
2018-06-25 15:41:57 +03:00
|
|
|
SPAPR_MEMORY_BLOCK_SIZE / MiB);
|
2016-01-25 14:46:47 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (machine->maxram_size % SPAPR_MEMORY_BLOCK_SIZE) {
|
|
|
|
error_setg(errp, "Maximum memory size 0x" RAM_ADDR_FMT
|
2018-06-25 15:42:24 +03:00
|
|
|
" is not aligned to %" PRIu64 " MiB",
|
2016-01-25 14:46:47 +03:00
|
|
|
machine->ram_size,
|
2018-06-25 15:41:57 +03:00
|
|
|
SPAPR_MEMORY_BLOCK_SIZE / MiB);
|
2016-01-25 14:46:47 +03:00
|
|
|
return;
|
2015-08-12 06:16:48 +03:00
|
|
|
}
|
|
|
|
|
2019-08-09 09:57:22 +03:00
|
|
|
for (i = 0; i < machine->numa_state->num_nodes; i++) {
|
2019-08-09 09:57:24 +03:00
|
|
|
if (machine->numa_state->nodes[i].node_mem % SPAPR_MEMORY_BLOCK_SIZE) {
|
2016-01-25 14:46:47 +03:00
|
|
|
error_setg(errp,
|
|
|
|
"Node %d memory size 0x%" PRIx64
|
2018-06-25 15:42:24 +03:00
|
|
|
" is not aligned to %" PRIu64 " MiB",
|
2019-08-09 09:57:24 +03:00
|
|
|
i, machine->numa_state->nodes[i].node_mem,
|
2018-06-25 15:41:57 +03:00
|
|
|
SPAPR_MEMORY_BLOCK_SIZE / MiB);
|
2016-01-25 14:46:47 +03:00
|
|
|
return;
|
2015-08-12 06:16:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
/* find cpu slot in machine->possible_cpus by core_id */
|
|
|
|
static CPUArchId *spapr_find_cpu_slot(MachineState *ms, uint32_t id, int *idx)
|
|
|
|
{
|
2019-05-18 23:54:22 +03:00
|
|
|
int index = id / ms->smp.threads;
|
2017-02-10 13:18:49 +03:00
|
|
|
|
|
|
|
if (index >= ms->possible_cpus->len) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (idx) {
|
|
|
|
*idx = index;
|
|
|
|
}
|
|
|
|
return &ms->possible_cpus->cpus[index];
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
static void spapr_set_vsmt_mode(SpaprMachineState *spapr, Error **errp)
|
2017-08-18 08:50:22 +03:00
|
|
|
{
|
2019-05-18 23:54:22 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
2019-10-03 15:02:00 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
2017-08-18 08:50:22 +03:00
|
|
|
Error *local_err = NULL;
|
|
|
|
bool vsmt_user = !!spapr->vsmt;
|
|
|
|
int kvm_smt = kvmppc_smt_threads();
|
|
|
|
int ret;
|
2019-05-18 23:54:22 +03:00
|
|
|
unsigned int smp_threads = ms->smp.threads;
|
2017-08-18 08:50:22 +03:00
|
|
|
|
2023-06-22 12:33:55 +03:00
|
|
|
if (tcg_enabled()) {
|
|
|
|
if (smp_threads > 1 &&
|
|
|
|
!ppc_type_check_compat(ms->cpu_type, CPU_POWERPC_LOGICAL_2_07, 0,
|
|
|
|
spapr->max_compat_pvr)) {
|
|
|
|
error_setg(errp, "TCG only supports SMT on POWER8 or newer CPUs");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (smp_threads > 8) {
|
|
|
|
error_setg(errp, "TCG cannot support more than 8 threads/core "
|
|
|
|
"on a pseries machine");
|
|
|
|
return;
|
|
|
|
}
|
2017-08-18 08:50:22 +03:00
|
|
|
}
|
|
|
|
if (!is_power_of_2(smp_threads)) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "Cannot support %d threads/core on a pseries "
|
|
|
|
"machine because it must be a power of 2", smp_threads);
|
|
|
|
return;
|
2017-08-18 08:50:22 +03:00
|
|
|
}
|
|
|
|
|
2023-07-14 14:18:16 +03:00
|
|
|
/* Determine the VSMT mode to use: */
|
2017-08-18 08:50:22 +03:00
|
|
|
if (vsmt_user) {
|
|
|
|
if (spapr->vsmt < smp_threads) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "Cannot support VSMT mode %d"
|
|
|
|
" because it must be >= threads/core (%d)",
|
|
|
|
spapr->vsmt, smp_threads);
|
|
|
|
return;
|
2017-08-18 08:50:22 +03:00
|
|
|
}
|
|
|
|
/* In this case, spapr->vsmt has been set by the command line */
|
2019-10-03 15:02:00 +03:00
|
|
|
} else if (!smc->smp_threads_vsmt) {
|
spapr: Adjust default VSMT value for better migration compatibility
fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the
"vsmt" parameter for the pseries machine type, which controls the spacing
of the vcpu ids of thread 0 for each virtual core. This was done to bring
some consistency and stability to how that was done, while still allowing
backwards compatibility for migration and otherwise.
The default value we used for vsmt was set to the max of the host's
advertised default number of threads and the number of vthreads per vcore
in the guest. This was done to continue running without extra parameters
on older KVM versions which don't allow the VSMT value to be changed.
Unfortunately, even that smaller than before leakage of host configuration
into guest visible configuration still breaks things. Specifically a guest
with 4 (or less) vthread/vcore will get a different vsmt value when
running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host. That means the
vcpu ids don't line up so you can't migrate between them, though you should
be able to.
Long term we really want to make vsmt == smp_threads for sufficiently
new machine types. However, that means that qemu will then require a
sufficiently recent KVM (one which supports changing VSMT) - that's still
not widely enough deployed to be really comfortable to do.
In the meantime we need some default that will work as often as
possible. This patch changes that default to 8 in all circumstances.
This does change guest visible behaviour (including for existing
machine versions) for many cases - just not the most common/important
case.
Following is case by case justification for why this is still the least
worst option. Note that any of the old behaviours can still be duplicated
after this patch, it's just that it requires manual intervention by
setting the vsmt property on the command line.
KVM HV on POWER8 host:
This is the overwhelmingly common case in production setups, and is
unchanged by design. POWER8 hosts will advertise a default VSMT mode
of 8, and > 8 vthreads/vcore isn't permitted
KVM HV on POWER7 host:
Will break, but POWER7s allowing KVM were never released to the public.
KVM HV on POWER9 host:
Not yet released to the public, breaking this now will reduce other
breakage later.
KVM HV on PowerPC 970:
Will theoretically break it, but it was barely supported to begin with
and already required various user visible hacks to work. Also so old
that I just don't care.
TCG:
This is the nastiest one; it means migration of TCG guests (without
manual vsmt setting) will break. Since TCG is rarely used in production
I think this is worth it for the other benefits. It does also remove
one more barrier to TCG<->KVM migration which could be interesting for
debugging applications.
KVM PR:
As with TCG, this will break migration of existing configurations,
without adding extra manual vsmt options. As with TCG, it is rare in
production so I think the benefits outweigh breakages.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
2018-01-15 09:51:33 +03:00
|
|
|
/*
|
|
|
|
* Default VSMT value is tricky, because we need it to be as
|
|
|
|
* consistent as possible (for migration), but this requires
|
|
|
|
* changing it for at least some existing cases. We pick 8 as
|
|
|
|
* the value that we'd get with KVM on POWER8, the
|
|
|
|
* overwhelmingly common case in production systems.
|
|
|
|
*/
|
2018-02-09 11:18:58 +03:00
|
|
|
spapr->vsmt = MAX(8, smp_threads);
|
2019-10-03 15:02:00 +03:00
|
|
|
} else {
|
|
|
|
spapr->vsmt = smp_threads;
|
2017-08-18 08:50:22 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* KVM: If necessary, set the SMT mode: */
|
|
|
|
if (kvm_enabled() && (spapr->vsmt != kvm_smt)) {
|
|
|
|
ret = kvmppc_set_smt_threads(spapr->vsmt);
|
|
|
|
if (ret) {
|
2018-01-16 07:37:37 +03:00
|
|
|
/* Looks like KVM isn't able to change VSMT mode */
|
2017-08-18 08:50:22 +03:00
|
|
|
error_setg(&local_err,
|
|
|
|
"Failed to set KVM's VSMT mode to %d (errno %d)",
|
|
|
|
spapr->vsmt, ret);
|
2018-01-16 07:37:37 +03:00
|
|
|
/* We can live with that if the default one is big enough
|
|
|
|
* for the number of threads, and a submultiple of the one
|
|
|
|
* we want. In this case we'll waste some vcpu ids, but
|
|
|
|
* behaviour will be correct */
|
|
|
|
if ((kvm_smt >= smp_threads) && ((spapr->vsmt % kvm_smt) == 0)) {
|
|
|
|
warn_report_err(local_err);
|
|
|
|
} else {
|
|
|
|
if (!vsmt_user) {
|
|
|
|
error_append_hint(&local_err,
|
|
|
|
"On PPC, a VM with %d threads/core"
|
|
|
|
" on a host with %d threads/core"
|
|
|
|
" requires the use of VSMT mode %d.\n",
|
|
|
|
smp_threads, kvm_smt, spapr->vsmt);
|
|
|
|
}
|
2019-11-27 22:14:34 +03:00
|
|
|
kvmppc_error_append_smt_possible_hint(&local_err);
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_propagate(errp, local_err);
|
2017-08-18 08:50:22 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* else TCG: nothing to do currently */
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
static void spapr_init_cpus(SpaprMachineState *spapr)
|
2018-02-27 18:23:07 +03:00
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(machine);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
|
2018-02-27 18:23:07 +03:00
|
|
|
const char *type = spapr_get_cpu_core_type(machine->cpu_type);
|
|
|
|
const CPUArchIdList *possible_cpus;
|
2019-05-18 23:54:22 +03:00
|
|
|
unsigned int smp_cpus = machine->smp.cpus;
|
|
|
|
unsigned int smp_threads = machine->smp.threads;
|
|
|
|
unsigned int max_cpus = machine->smp.max_cpus;
|
2018-02-27 18:23:07 +03:00
|
|
|
int boot_cores_nr = smp_cpus / smp_threads;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
possible_cpus = mc->possible_cpu_arch_ids(machine);
|
|
|
|
if (mc->has_hotpluggable_cpus) {
|
|
|
|
if (smp_cpus % smp_threads) {
|
|
|
|
error_report("smp_cpus (%u) must be multiple of threads (%u)",
|
|
|
|
smp_cpus, smp_threads);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
if (max_cpus % smp_threads) {
|
|
|
|
error_report("max_cpus (%u) must be multiple of threads (%u)",
|
|
|
|
max_cpus, smp_threads);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (max_cpus != smp_cpus) {
|
|
|
|
error_report("This machine version does not support CPU hotplug");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
boot_cores_nr = possible_cpus->len;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (smc->pre_2_10_has_unused_icps) {
|
2018-12-06 02:22:29 +03:00
|
|
|
for (i = 0; i < spapr_max_server_number(spapr); i++) {
|
2018-02-27 18:23:07 +03:00
|
|
|
/* Dummy entries get deregistered when real ICPState objects
|
|
|
|
* are registered during CPU core hotplug.
|
|
|
|
*/
|
|
|
|
pre_2_10_vmstate_register_dummy_icp(i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < possible_cpus->len; i++) {
|
|
|
|
int core_id = i * smp_threads;
|
|
|
|
|
|
|
|
if (mc->has_hotpluggable_cpus) {
|
|
|
|
spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_CPU,
|
|
|
|
spapr_vcpu_id(spapr, core_id));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i < boot_cores_nr) {
|
|
|
|
Object *core = object_new(type);
|
|
|
|
int nr_threads = smp_threads;
|
|
|
|
|
|
|
|
/* Handle the partially filled core for older machine types */
|
|
|
|
if ((i + 1) * smp_threads >= smp_cpus) {
|
|
|
|
nr_threads = smp_cpus - i * smp_threads;
|
|
|
|
}
|
|
|
|
|
qom: Put name parameter before value / visitor parameter
The object_property_set_FOO() setters take property name and value in
an unusual order:
void object_property_set_FOO(Object *obj, FOO_TYPE value,
const char *name, Error **errp)
Having to pass value before name feels grating. Swap them.
Same for object_property_set(), object_property_get(), and
object_property_parse().
Convert callers with this Coccinelle script:
@@
identifier fun = {
object_property_get, object_property_parse, object_property_set_str,
object_property_set_link, object_property_set_bool,
object_property_set_int, object_property_set_uint, object_property_set,
object_property_set_qobject
};
expression obj, v, name, errp;
@@
- fun(obj, v, name, errp)
+ fun(obj, name, v, errp)
Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error
message "no position information". Convert that one manually.
Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by
ARMSSE being used both as typedef and function-like macro there.
Convert manually.
Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused
by RXCPU being used both as typedef and function-like macro there.
Convert manually. The other files using RXCPU that way don't need
conversion.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200707160613.848843-27-armbru@redhat.com>
[Straightforwad conflict with commit 2336172d9b "audio: set default
value for pcspk.iobase property" resolved]
2020-07-07 19:05:54 +03:00
|
|
|
object_property_set_int(core, "nr-threads", nr_threads,
|
2018-02-27 18:23:07 +03:00
|
|
|
&error_fatal);
|
qom: Put name parameter before value / visitor parameter
The object_property_set_FOO() setters take property name and value in
an unusual order:
void object_property_set_FOO(Object *obj, FOO_TYPE value,
const char *name, Error **errp)
Having to pass value before name feels grating. Swap them.
Same for object_property_set(), object_property_get(), and
object_property_parse().
Convert callers with this Coccinelle script:
@@
identifier fun = {
object_property_get, object_property_parse, object_property_set_str,
object_property_set_link, object_property_set_bool,
object_property_set_int, object_property_set_uint, object_property_set,
object_property_set_qobject
};
expression obj, v, name, errp;
@@
- fun(obj, v, name, errp)
+ fun(obj, name, v, errp)
Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error
message "no position information". Convert that one manually.
Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by
ARMSSE being used both as typedef and function-like macro there.
Convert manually.
Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused
by RXCPU being used both as typedef and function-like macro there.
Convert manually. The other files using RXCPU that way don't need
conversion.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200707160613.848843-27-armbru@redhat.com>
[Straightforwad conflict with commit 2336172d9b "audio: set default
value for pcspk.iobase property" resolved]
2020-07-07 19:05:54 +03:00
|
|
|
object_property_set_int(core, CPU_CORE_PROP_CORE_ID, core_id,
|
2018-02-27 18:23:07 +03:00
|
|
|
&error_fatal);
|
qdev: Convert bus-less devices to qdev_realize() with Coccinelle
All remaining conversions to qdev_realize() are for bus-less devices.
Coccinelle script:
// only correct for bus-less @dev!
@@
expression errp;
expression dev;
@@
- qdev_init_nofail(dev);
+ qdev_realize(dev, NULL, &error_fatal);
@ depends on !(file in "hw/core/qdev.c") && !(file in "hw/core/bus.c")@
expression errp;
expression dev;
symbol true;
@@
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize(DEVICE(dev), NULL, errp);
@ depends on !(file in "hw/core/qdev.c") && !(file in "hw/core/bus.c")@
expression errp;
expression dev;
symbol true;
@@
- object_property_set_bool(dev, true, "realized", errp);
+ qdev_realize(DEVICE(dev), NULL, errp);
Note that Coccinelle chokes on ARMSSE typedef vs. macro in
hw/arm/armsse.c. Worked around by temporarily renaming the macro for
the spatch run.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-57-armbru@redhat.com>
2020-06-10 08:32:45 +03:00
|
|
|
qdev_realize(DEVICE(core), NULL, &error_fatal);
|
2018-08-30 08:54:40 +03:00
|
|
|
|
|
|
|
object_unref(core);
|
2018-02-27 18:23:07 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-21 03:35:09 +03:00
|
|
|
static PCIHostState *spapr_create_default_phb(void)
|
|
|
|
{
|
|
|
|
DeviceState *dev;
|
|
|
|
|
qdev: Convert uses of qdev_create() with Coccinelle
This is the transformation explained in the commit before previous.
Takes care of just one pattern that needs conversion. More to come in
this series.
Coccinelle script:
@ depends on !(file in "hw/arm/highbank.c")@
expression bus, type_name, dev, expr;
@@
- dev = qdev_create(bus, type_name);
+ dev = qdev_new(type_name);
... when != dev = expr
- qdev_init_nofail(dev);
+ qdev_realize_and_unref(dev, bus, &error_fatal);
@@
expression bus, type_name, dev, expr;
identifier DOWN;
@@
- dev = DOWN(qdev_create(bus, type_name));
+ dev = DOWN(qdev_new(type_name));
... when != dev = expr
- qdev_init_nofail(DEVICE(dev));
+ qdev_realize_and_unref(DEVICE(dev), bus, &error_fatal);
@@
expression bus, type_name, expr;
identifier dev;
@@
- DeviceState *dev = qdev_create(bus, type_name);
+ DeviceState *dev = qdev_new(type_name);
... when != dev = expr
- qdev_init_nofail(dev);
+ qdev_realize_and_unref(dev, bus, &error_fatal);
@@
expression bus, type_name, dev, expr, errp;
symbol true;
@@
- dev = qdev_create(bus, type_name);
+ dev = qdev_new(type_name);
... when != dev = expr
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize_and_unref(dev, bus, errp);
@@
expression bus, type_name, expr, errp;
identifier dev;
symbol true;
@@
- DeviceState *dev = qdev_create(bus, type_name);
+ DeviceState *dev = qdev_new(type_name);
... when != dev = expr
- object_property_set_bool(OBJECT(dev), true, "realized", errp);
+ qdev_realize_and_unref(dev, bus, errp);
The first rule exempts hw/arm/highbank.c, because it matches along two
control flow paths there, with different @type_name. Covered by the
next commit's manual conversions.
Missing #include "qapi/error.h" added manually.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-10-armbru@redhat.com>
[Conflicts in hw/misc/empty_slot.c and hw/sparc/leon3.c resolved]
2020-06-10 08:31:58 +03:00
|
|
|
dev = qdev_new(TYPE_SPAPR_PCI_HOST_BRIDGE);
|
2018-12-21 03:35:09 +03:00
|
|
|
qdev_prop_set_uint32(dev, "index", 0);
|
sysbus: Convert to sysbus_realize() etc. with Coccinelle
Convert from qdev_realize(), qdev_realize_and_unref() with null @bus
argument to sysbus_realize(), sysbus_realize_and_unref().
Coccinelle script:
@@
expression dev, errp;
@@
- qdev_realize(DEVICE(dev), NULL, errp);
+ sysbus_realize(SYS_BUS_DEVICE(dev), errp);
@@
expression sysbus_dev, dev, errp;
@@
+ sysbus_dev = SYS_BUS_DEVICE(dev);
- qdev_realize_and_unref(dev, NULL, errp);
+ sysbus_realize_and_unref(sysbus_dev, errp);
- sysbus_dev = SYS_BUS_DEVICE(dev);
@@
expression sysbus_dev, dev, errp;
expression expr;
@@
sysbus_dev = SYS_BUS_DEVICE(dev);
... when != dev = expr;
- qdev_realize_and_unref(dev, NULL, errp);
+ sysbus_realize_and_unref(sysbus_dev, errp);
@@
expression dev, errp;
@@
- qdev_realize_and_unref(DEVICE(dev), NULL, errp);
+ sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), errp);
@@
expression dev, errp;
@@
- qdev_realize_and_unref(dev, NULL, errp);
+ sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), errp);
Whitespace changes minimized manually.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200610053247.1583243-46-armbru@redhat.com>
[Conflicts in hw/misc/empty_slot.c and hw/sparc/leon3.c resolved]
2020-06-10 08:32:34 +03:00
|
|
|
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
|
2018-12-21 03:35:09 +03:00
|
|
|
|
|
|
|
return PCI_HOST_BRIDGE(dev);
|
|
|
|
}
|
|
|
|
|
2019-11-29 03:49:04 +03:00
|
|
|
static hwaddr spapr_rma_size(SpaprMachineState *spapr, Error **errp)
|
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
|
|
|
hwaddr rma_size = machine->ram_size;
|
|
|
|
hwaddr node0_size = spapr_node0_size(machine);
|
|
|
|
|
|
|
|
/* RMA has to fit in the first NUMA node */
|
|
|
|
rma_size = MIN(rma_size, node0_size);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* VRMA access is via a special 1TiB SLB mapping, so the RMA can
|
|
|
|
* never exceed that
|
|
|
|
*/
|
|
|
|
rma_size = MIN(rma_size, 1 * TiB);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clamp the RMA size based on machine type. This is for
|
|
|
|
* migration compatibility with older qemu versions, which limited
|
|
|
|
* the RMA size for complicated and mostly bad reasons.
|
|
|
|
*/
|
|
|
|
if (smc->rma_limit) {
|
|
|
|
rma_size = MIN(rma_size, smc->rma_limit);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rma_size < MIN_RMA_SLOF) {
|
|
|
|
error_setg(errp,
|
|
|
|
"pSeries SLOF firmware requires >= %" HWADDR_PRIx
|
|
|
|
"ldMiB guest RMA (Real Mode Area memory)",
|
|
|
|
MIN_RMA_SLOF / MiB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return rma_size;
|
|
|
|
}
|
|
|
|
|
2020-10-12 13:15:21 +03:00
|
|
|
static void spapr_create_nvdimm_dr_connectors(SpaprMachineState *spapr)
|
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(spapr);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < machine->ram_slots; i++) {
|
|
|
|
spapr_dr_connector_new(OBJECT(spapr), TYPE_SPAPR_DRC_PMEM, i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 08:15:20 +04:00
|
|
|
/* pSeries LPAR / sPAPR hardware init */
|
2017-12-08 04:47:34 +03:00
|
|
|
static void spapr_machine_init(MachineState *machine)
|
2011-04-01 08:15:20 +04: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(machine);
|
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(machine);
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(machine);
|
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 08:51:55 +03:00
|
|
|
const char *bios_default = spapr->vof ? FW_FILE_NAME_VOF : FW_FILE_NAME;
|
|
|
|
const char *bios_name = machine->firmware ?: bios_default;
|
2022-03-02 08:51:39 +03:00
|
|
|
g_autofree char *filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
|
2014-05-07 18:42:57 +04:00
|
|
|
const char *kernel_filename = machine->kernel_filename;
|
|
|
|
const char *initrd_filename = machine->initrd_filename;
|
2012-08-20 21:08:05 +04:00
|
|
|
PCIHostState *phb;
|
2022-05-07 08:48:26 +03:00
|
|
|
bool has_vga;
|
2011-04-01 08:15:20 +04:00
|
|
|
int i;
|
2011-10-03 14:56:38 +04:00
|
|
|
MemoryRegion *sysmem = get_system_memory();
|
spapr: Locate RTAS and device-tree based on real RMA
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl, defined RTAS_MAX_ADDR]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-07-21 07:02:04 +04:00
|
|
|
long load_limit, fw_size;
|
2017-05-12 08:46:11 +03:00
|
|
|
Error *resize_hpt_err = NULL;
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2022-03-02 08:51:39 +03:00
|
|
|
if (!filename) {
|
|
|
|
error_report("Could not find LPAR firmware '%s'", bios_name);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
fw_size = load_image_targphys(filename, 0, FW_MAX_SIZE);
|
|
|
|
if (fw_size <= 0) {
|
|
|
|
error_report("Could not load LPAR firmware '%s'", filename);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2020-04-08 08:10:03 +03:00
|
|
|
/*
|
|
|
|
* if Secure VM (PEF) support is configured, then initialize it
|
|
|
|
*/
|
|
|
|
pef_kvm_init(machine->cgs, &error_fatal);
|
|
|
|
|
2016-03-04 12:24:28 +03:00
|
|
|
msi_nonbroken = true;
|
2012-08-07 20:10:37 +04:00
|
|
|
|
2011-11-01 20:49:05 +04:00
|
|
|
QLIST_INIT(&spapr->phbs);
|
2017-05-24 10:01:48 +03:00
|
|
|
QTAILQ_INIT(&spapr->pending_dimm_unplugs);
|
2011-11-01 20:49:05 +04:00
|
|
|
|
2018-06-14 09:37:28 +03:00
|
|
|
/* Determine capabilities to run with */
|
|
|
|
spapr_caps_init(spapr);
|
|
|
|
|
2017-05-12 08:46:11 +03:00
|
|
|
kvmppc_check_papr_resize_hpt(&resize_hpt_err);
|
|
|
|
if (spapr->resize_hpt == SPAPR_RESIZE_HPT_DEFAULT) {
|
|
|
|
/*
|
|
|
|
* If the user explicitly requested a mode we should either
|
|
|
|
* supply it, or fail completely (which we do below). But if
|
|
|
|
* it's not set explicitly, we reset our mode to something
|
|
|
|
* that works
|
|
|
|
*/
|
|
|
|
if (resize_hpt_err) {
|
|
|
|
spapr->resize_hpt = SPAPR_RESIZE_HPT_DISABLED;
|
|
|
|
error_free(resize_hpt_err);
|
|
|
|
resize_hpt_err = NULL;
|
|
|
|
} else {
|
|
|
|
spapr->resize_hpt = smc->resize_hpt_default;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(spapr->resize_hpt != SPAPR_RESIZE_HPT_DEFAULT);
|
|
|
|
|
|
|
|
if ((spapr->resize_hpt != SPAPR_RESIZE_HPT_DISABLED) && resize_hpt_err) {
|
|
|
|
/*
|
|
|
|
* User requested HPT resize, but this host can't supply it. Bail out
|
|
|
|
*/
|
|
|
|
error_report_err(resize_hpt_err);
|
|
|
|
exit(1);
|
|
|
|
}
|
2020-06-30 12:03:32 +03:00
|
|
|
error_free(resize_hpt_err);
|
2017-05-12 08:46:11 +03:00
|
|
|
|
2019-11-29 03:49:04 +03:00
|
|
|
spapr->rma_size = spapr_rma_size(spapr, &error_fatal);
|
2013-11-25 07:14:50 +04:00
|
|
|
|
spapr: Locate RTAS and device-tree based on real RMA
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl, defined RTAS_MAX_ADDR]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[agraf: fix compilation on 32bit hosts]
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-07-21 07:02:04 +04:00
|
|
|
/* Setup a load limit for the ramdisk leaving room for SLOF and FDT */
|
2021-03-31 05:51:23 +03:00
|
|
|
load_limit = MIN(spapr->rma_size, FDT_MAX_ADDR) - FW_OVERHEAD;
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2018-12-06 02:22:26 +03:00
|
|
|
/*
|
|
|
|
* VSMT must be set in order to be able to compute VCPU ids, ie to
|
2018-12-06 02:22:29 +03:00
|
|
|
* call spapr_max_server_number() or spapr_vcpu_id().
|
2018-12-06 02:22:26 +03:00
|
|
|
*/
|
|
|
|
spapr_set_vsmt_mode(spapr, &error_fatal);
|
|
|
|
|
2013-03-13 19:53:28 +04:00
|
|
|
/* Set up Interrupt Controller before we create the VCPUs */
|
2018-12-06 02:22:27 +03:00
|
|
|
spapr_irq_init(spapr, &error_fatal);
|
2013-03-13 19:53:28 +04:00
|
|
|
|
2017-10-04 11:43:18 +03:00
|
|
|
/* Set up containers for ibm,client-architecture-support negotiated options
|
|
|
|
*/
|
2016-10-25 07:47:28 +03:00
|
|
|
spapr->ov5 = spapr_ovec_new();
|
|
|
|
spapr->ov5_cas = spapr_ovec_new();
|
|
|
|
|
2015-08-12 06:16:48 +03:00
|
|
|
if (smc->dr_lmb_enabled) {
|
2016-10-25 07:47:28 +03:00
|
|
|
spapr_ovec_set(spapr->ov5, OV5_DRCONF_MEMORY);
|
2016-01-25 14:46:47 +03:00
|
|
|
spapr_validate_node_memory(machine, &error_fatal);
|
2015-08-12 06:16:48 +03:00
|
|
|
}
|
|
|
|
|
2016-10-25 07:47:30 +03:00
|
|
|
spapr_ovec_set(spapr->ov5, OV5_FORM1_AFFINITY);
|
|
|
|
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
/* Do not advertise FORM2 NUMA support for pseries-6.1 and older */
|
|
|
|
if (!smc->pre_6_2_numa_affinity) {
|
|
|
|
spapr_ovec_set(spapr->ov5, OV5_FORM2_AFFINITY);
|
|
|
|
}
|
|
|
|
|
2016-10-27 05:20:26 +03:00
|
|
|
/* advertise support for dedicated HP event source to guests */
|
|
|
|
if (spapr->use_hotplug_event_source) {
|
|
|
|
spapr_ovec_set(spapr->ov5, OV5_HP_EVT);
|
|
|
|
}
|
|
|
|
|
2017-07-12 10:56:06 +03:00
|
|
|
/* advertise support for HPT resizing */
|
|
|
|
if (spapr->resize_hpt != SPAPR_RESIZE_HPT_DISABLED) {
|
|
|
|
spapr_ovec_set(spapr->ov5, OV5_HPT_RESIZE);
|
|
|
|
}
|
|
|
|
|
2018-04-19 09:47:35 +03:00
|
|
|
/* advertise support for ibm,dyamic-memory-v2 */
|
|
|
|
spapr_ovec_set(spapr->ov5, OV5_DRMEM_V2);
|
|
|
|
|
2018-12-18 01:34:42 +03:00
|
|
|
/* advertise XIVE on POWER9 machines */
|
2019-09-25 08:12:07 +03:00
|
|
|
if (spapr->irq->xive) {
|
2019-03-28 13:00:44 +03:00
|
|
|
spapr_ovec_set(spapr->ov5, OV5_XIVE_EXPLOIT);
|
2018-12-18 01:34:42 +03:00
|
|
|
}
|
|
|
|
|
2011-04-01 08:15:20 +04:00
|
|
|
/* init CPUs */
|
2016-11-08 08:33:32 +03:00
|
|
|
spapr_init_cpus(spapr);
|
2011-04-01 08:15:20 +04:00
|
|
|
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
/* Init numa_assoc_array */
|
|
|
|
spapr_numa_associativity_init(spapr, machine);
|
|
|
|
|
2018-05-04 00:16:59 +03:00
|
|
|
if ((!kvm_enabled() || kvmppc_has_cap_mmu_radix()) &&
|
2018-06-14 09:33:58 +03:00
|
|
|
ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00, 0,
|
|
|
|
spapr->max_compat_pvr)) {
|
2020-03-25 18:25:36 +03:00
|
|
|
spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
|
2018-05-04 00:16:59 +03:00
|
|
|
/* KVM and TCG always allow GTSE with radix... */
|
|
|
|
spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
|
|
|
|
}
|
|
|
|
/* ... but not with hash (currently). */
|
|
|
|
|
2015-05-07 08:33:59 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
/* Enable H_LOGICAL_CI_* so SLOF can talk to in-kernel devices */
|
|
|
|
kvmppc_enable_logical_ci_hcalls();
|
2015-09-08 04:25:13 +03:00
|
|
|
kvmppc_enable_set_mode_hcall();
|
2016-08-30 04:02:47 +03:00
|
|
|
|
|
|
|
/* H_CLEAR_MOD/_REF are mandatory in PAPR, but off by default */
|
|
|
|
kvmppc_enable_clear_ref_mod_hcalls();
|
2019-03-06 09:06:08 +03:00
|
|
|
|
|
|
|
/* Enable H_PAGE_INIT */
|
|
|
|
kvmppc_enable_h_page_init();
|
2015-05-07 08:33:59 +03:00
|
|
|
}
|
|
|
|
|
2020-02-19 19:09:41 +03:00
|
|
|
/* map RAM */
|
|
|
|
memory_region_add_subregion(sysmem, 0, machine->ram);
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2015-06-29 11:44:27 +03:00
|
|
|
/* initialize hotplug memory address space */
|
|
|
|
if (machine->ram_size < machine->maxram_size) {
|
2018-04-23 19:51:25 +03:00
|
|
|
ram_addr_t device_mem_size = machine->maxram_size - machine->ram_size;
|
2023-06-23 15:45:47 +03:00
|
|
|
hwaddr device_mem_base;
|
|
|
|
|
2016-06-02 17:07:37 +03:00
|
|
|
/*
|
|
|
|
* Limit the number of hotpluggable memory slots to half the number
|
|
|
|
* slots that KVM supports, leaving the other half for PCI and other
|
|
|
|
* devices. However ensure that number of slots doesn't drop below 32.
|
|
|
|
*/
|
|
|
|
int max_memslots = kvm_enabled() ? kvm_get_max_memslots() / 2 :
|
|
|
|
SPAPR_MAX_RAM_SLOTS;
|
2015-06-29 11:44:27 +03:00
|
|
|
|
2016-06-02 17:07:37 +03:00
|
|
|
if (max_memslots < SPAPR_MAX_RAM_SLOTS) {
|
|
|
|
max_memslots = SPAPR_MAX_RAM_SLOTS;
|
|
|
|
}
|
|
|
|
if (machine->ram_slots > max_memslots) {
|
2016-01-20 04:58:55 +03:00
|
|
|
error_report("Specified number of memory slots %"
|
|
|
|
PRIu64" exceeds max supported %d",
|
2016-06-02 17:07:37 +03:00
|
|
|
machine->ram_slots, max_memslots);
|
2016-01-20 04:58:55 +03:00
|
|
|
exit(1);
|
2015-06-29 11:44:27 +03:00
|
|
|
}
|
|
|
|
|
2023-06-23 15:45:47 +03:00
|
|
|
device_mem_base = ROUND_UP(machine->ram_size, SPAPR_DEVICE_MEM_ALIGN);
|
|
|
|
machine_memory_devices_init(machine, device_mem_base, device_mem_size);
|
2015-06-29 11:44:27 +03:00
|
|
|
}
|
|
|
|
|
2015-08-12 06:16:48 +03:00
|
|
|
if (smc->dr_lmb_enabled) {
|
|
|
|
spapr_create_lmb_dr_connectors(spapr);
|
|
|
|
}
|
|
|
|
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
if (mc->nvdimm_supported) {
|
|
|
|
spapr_create_nvdimm_dr_connectors(spapr);
|
|
|
|
}
|
|
|
|
|
2016-10-27 05:20:26 +03:00
|
|
|
/* Set up RTAS event infrastructure */
|
2012-10-08 22:17:39 +04:00
|
|
|
spapr_events_init(spapr);
|
|
|
|
|
2015-02-06 06:55:47 +03:00
|
|
|
/* Set up the RTC RTAS interfaces */
|
2015-02-06 06:55:51 +03:00
|
|
|
spapr_rtc_create(spapr);
|
2015-02-06 06:55:47 +03:00
|
|
|
|
Implement the PAPR (pSeries) virtualized interrupt controller (xics)
PAPR defines an interrupt control architecture which is logically divided
into ICS (Interrupt Control Presentation, each unit is responsible for
presenting interrupts to a particular "interrupt server", i.e. CPU) and
ICS (Interrupt Control Source, each unit responsible for one or more
hardware interrupts as numbered globally across the system). All PAPR
virtual IO devices expect to deliver interrupts via this mechanism. In
Linux, this interrupt controller system is handled by the "xics" driver.
On pSeries systems, access to the interrupt controller is virtualized via
hypercalls and RTAS methods. However, the virtualized interface is very
similar to the underlying interrupt controller hardware, and similar PICs
exist un-virtualized in some other systems.
This patch implements both the ICP and ICS sides of the PAPR interrupt
controller. For now, only the hypercall virtualized interface is provided,
however it would be relatively straightforward to graft an emulated
register interface onto the underlying interrupt logic if we want to add
a machine with a hardware ICS/ICP system in the future.
There are some limitations in this implementation: it is assumed for now
that only one instance of the ICS exists, although a full xics system can
have several, each responsible for a different group of hardware irqs.
ICP/ICS can handle both level-sensitve (LSI) and message signalled (MSI)
interrupt inputs. For now, this implementation supports only MSI
interrupts, since that is used by PAPR virtual IO devices.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-01 08:15:25 +04:00
|
|
|
/* Set up VIO bus */
|
2011-04-01 08:15:21 +04:00
|
|
|
spapr->vio_bus = spapr_vio_bus_init();
|
|
|
|
|
2020-11-03 11:26:05 +03:00
|
|
|
for (i = 0; serial_hd(i); i++) {
|
|
|
|
spapr_vty_create(spapr->vio_bus, serial_hd(i));
|
2011-04-01 08:15:21 +04:00
|
|
|
}
|
2011-04-01 08:15:20 +04:00
|
|
|
|
2012-11-12 20:46:57 +04:00
|
|
|
/* We always have at least the nvram device on VIO */
|
|
|
|
spapr_create_nvram(spapr);
|
|
|
|
|
2019-02-19 20:18:23 +03:00
|
|
|
/*
|
|
|
|
* Setup hotplug / dynamic-reconfiguration connectors. top-level
|
|
|
|
* connectors (described in root DT node's "ibm,drc-types" property)
|
|
|
|
* are pre-initialized here. additional child connectors (such as
|
|
|
|
* connectors for a PHBs PCI slots) are added as needed during their
|
|
|
|
* parent's realization.
|
|
|
|
*/
|
|
|
|
if (smc->dr_phb_enabled) {
|
|
|
|
for (i = 0; i < SPAPR_MAX_PHBS; i++) {
|
|
|
|
spapr_dr_connector_new(OBJECT(machine), TYPE_SPAPR_DRC_PHB, i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-10-30 21:16:46 +04:00
|
|
|
/* Set up PCI */
|
2012-08-07 20:10:33 +04:00
|
|
|
spapr_pci_rtas_init();
|
|
|
|
|
2018-12-21 03:35:09 +03:00
|
|
|
phb = spapr_create_default_phb();
|
2011-10-30 21:16:46 +04:00
|
|
|
|
2011-05-26 13:52:44 +04:00
|
|
|
for (i = 0; i < nb_nics; i++) {
|
2011-04-01 08:15:29 +04:00
|
|
|
NICInfo *nd = &nd_table[i];
|
|
|
|
|
|
|
|
if (!nd->model) {
|
2018-03-09 10:01:38 +03:00
|
|
|
nd->model = g_strdup("spapr-vlan");
|
2011-04-01 08:15:29 +04:00
|
|
|
}
|
|
|
|
|
2018-03-09 10:01:38 +03:00
|
|
|
if (g_str_equal(nd->model, "spapr-vlan") ||
|
|
|
|
g_str_equal(nd->model, "ibmveth")) {
|
2012-04-25 21:55:41 +04:00
|
|
|
spapr_vlan_create(spapr->vio_bus, nd);
|
2011-04-01 08:15:29 +04:00
|
|
|
} else {
|
2013-06-06 12:48:51 +04:00
|
|
|
pci_nic_init_nofail(&nd_table[i], phb->bus, nd->model, NULL);
|
2011-04-01 08:15:29 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 08:15:31 +04:00
|
|
|
for (i = 0; i <= drive_get_max_bus(IF_SCSI); i++) {
|
2012-04-25 21:55:41 +04:00
|
|
|
spapr_vscsi_create(spapr->vio_bus);
|
2011-04-01 08:15:31 +04:00
|
|
|
}
|
|
|
|
|
2012-08-06 20:42:00 +04:00
|
|
|
/* Graphics */
|
2022-05-07 08:48:26 +03:00
|
|
|
has_vga = spapr_vga_init(phb->bus, &error_fatal);
|
|
|
|
if (has_vga) {
|
|
|
|
spapr->want_stdout_path = !machine->enable_graphics;
|
2015-03-23 20:05:28 +03:00
|
|
|
machine->usb |= defaults_enabled() && !machine->usb_disabled;
|
2022-05-07 08:48:26 +03:00
|
|
|
} else {
|
|
|
|
spapr->want_stdout_path = true;
|
2012-08-06 20:42:00 +04:00
|
|
|
}
|
|
|
|
|
2015-01-06 16:29:16 +03:00
|
|
|
if (machine->usb) {
|
2015-12-09 15:34:13 +03:00
|
|
|
if (smc->use_ohci_by_default) {
|
|
|
|
pci_create_simple(phb->bus, -1, "pci-ohci");
|
|
|
|
} else {
|
|
|
|
pci_create_simple(phb->bus, -1, "nec-usb-xhci");
|
|
|
|
}
|
2015-02-04 15:28:14 +03:00
|
|
|
|
2022-05-07 08:48:26 +03:00
|
|
|
if (has_vga) {
|
2015-02-04 15:28:14 +03:00
|
|
|
USBBus *usb_bus = usb_bus_find(-1);
|
|
|
|
|
|
|
|
usb_create_simple(usb_bus, "usb-kbd");
|
|
|
|
usb_create_simple(usb_bus, "usb-mouse");
|
2012-08-16 06:03:56 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 08:15:20 +04:00
|
|
|
if (kernel_filename) {
|
2022-05-04 09:55:36 +03:00
|
|
|
uint64_t loaded_addr = 0;
|
|
|
|
|
2019-01-15 15:18:03 +03:00
|
|
|
spapr->kernel_size = load_elf(kernel_filename, NULL,
|
2020-02-03 06:29:42 +03:00
|
|
|
translate_kernel_address, spapr,
|
2022-05-04 09:55:36 +03:00
|
|
|
NULL, &loaded_addr, NULL, NULL, 1,
|
2016-10-20 07:31:45 +03:00
|
|
|
PPC_ELF_MACHINE, 0, 0);
|
|
|
|
if (spapr->kernel_size == ELF_LOAD_WRONG_ENDIAN) {
|
2019-01-15 15:18:03 +03:00
|
|
|
spapr->kernel_size = load_elf(kernel_filename, NULL,
|
2020-07-05 20:22:11 +03:00
|
|
|
translate_kernel_address, spapr,
|
2022-05-04 09:55:36 +03:00
|
|
|
NULL, &loaded_addr, NULL, NULL, 0,
|
2020-07-05 20:22:11 +03:00
|
|
|
PPC_ELF_MACHINE, 0, 0);
|
2016-10-20 07:31:45 +03:00
|
|
|
spapr->kernel_le = spapr->kernel_size > 0;
|
2013-09-25 11:40:15 +04:00
|
|
|
}
|
2016-10-20 07:31:45 +03:00
|
|
|
if (spapr->kernel_size < 0) {
|
|
|
|
error_report("error loading %s: %s", kernel_filename,
|
|
|
|
load_elf_strerror(spapr->kernel_size));
|
2011-04-01 08:15:20 +04:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2022-05-04 09:55:36 +03:00
|
|
|
if (spapr->kernel_addr != loaded_addr) {
|
|
|
|
warn_report("spapr: kernel_addr changed from 0x%"PRIx64
|
|
|
|
" to 0x%"PRIx64,
|
|
|
|
spapr->kernel_addr, loaded_addr);
|
|
|
|
spapr->kernel_addr = loaded_addr;
|
|
|
|
}
|
|
|
|
|
2011-04-01 08:15:20 +04:00
|
|
|
/* load initrd */
|
|
|
|
if (initrd_filename) {
|
2012-01-11 23:46:28 +04:00
|
|
|
/* Try to locate the initrd in the gap between the kernel
|
|
|
|
* and the firmware. Add a bit of space just in case
|
|
|
|
*/
|
2020-02-03 06:29:42 +03:00
|
|
|
spapr->initrd_base = (spapr->kernel_addr + spapr->kernel_size
|
2016-10-20 07:31:45 +03:00
|
|
|
+ 0x1ffff) & ~0xffff;
|
|
|
|
spapr->initrd_size = load_image_targphys(initrd_filename,
|
|
|
|
spapr->initrd_base,
|
|
|
|
load_limit
|
|
|
|
- spapr->initrd_base);
|
|
|
|
if (spapr->initrd_size < 0) {
|
2016-01-20 04:58:55 +03:00
|
|
|
error_report("could not load initial ram disk '%s'",
|
|
|
|
initrd_filename);
|
2011-04-01 08:15:20 +04:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
2012-01-11 23:46:28 +04:00
|
|
|
}
|
Delay creation of pseries device tree until reset
At present, the 'pseries' machine creates a flattened device tree in the
machine->init function to pass to either the guest kernel or to firmware.
However, the machine->init function runs before processing of -device
command line options, which means that the device tree so created will
be (incorrectly) missing devices specified that way.
Supplying a correct device tree is, in any case, part of the required
platform entry conditions. Therefore, this patch moves the creation and
loading of the device tree from machine->init to a reset callback. The
setup of entry point address and initial register state moves with it,
which leads to a slight cleanup.
This is not, alas, quite enough to make a fully working reset for pseries.
For that we would need to reload the firmware images, which on this
machine are loaded into RAM. It's a step in the right direction, though.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-04-05 09:12:10 +04:00
|
|
|
|
2015-07-02 09:23:04 +03:00
|
|
|
/* FIXME: Should register things through the MachineState's qdev
|
|
|
|
* interface, this is a legacy from the sPAPREnvironment structure
|
|
|
|
* which predated MachineState but had a similar function */
|
2013-07-18 23:33:01 +04:00
|
|
|
vmstate_register(NULL, 0, &vmstate_spapr, spapr);
|
2019-10-16 05:29:30 +03:00
|
|
|
register_savevm_live("spapr/htab", VMSTATE_INSTANCE_ID_ANY, 1,
|
2013-07-18 23:33:01 +04:00
|
|
|
&savevm_htab_handlers, spapr);
|
|
|
|
|
qdev: Drop qbus_set_hotplug_handler() parameter @errp
qbus_set_hotplug_handler() is a simple wrapper around
object_property_set_link().
object_property_set_link() fails when the property doesn't exist, is
not settable, or its .check() method fails. These are all programming
errors here, so passing &error_abort to qbus_set_hotplug_handler() is
appropriate.
Most of its callers do. Exceptions:
* pcie_cap_slot_init(), shpc_init(), spapr_phb_realize() pass NULL,
i.e. they ignore errors.
* spapr_machine_init() passes &error_fatal.
* s390_pcihost_realize(), virtio_serial_device_realize(),
s390_pcihost_plug() pass the error to their callers. The latter two
keep going after the error, which looks wrong.
Drop the @errp parameter, and instead pass &error_abort to
object_property_set_link().
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200630090351.1247703-15-armbru@redhat.com>
2020-06-30 12:03:39 +03:00
|
|
|
qbus_set_hotplug_handler(sysbus_get_default(), OBJECT(machine));
|
2019-02-19 20:18:49 +03:00
|
|
|
|
2015-03-18 15:30:44 +03:00
|
|
|
qemu_register_boot_set(spapr_boot_set, spapr);
|
2017-01-27 15:24:58 +03:00
|
|
|
|
2019-07-22 09:17:52 +03:00
|
|
|
/*
|
|
|
|
* Nothing needs to be done to resume a suspended guest because
|
|
|
|
* suspending does not change the machine state, so no need for
|
|
|
|
* a ->wakeup method.
|
|
|
|
*/
|
|
|
|
qemu_register_wakeup_support();
|
|
|
|
|
2017-01-27 15:24:58 +03:00
|
|
|
if (kvm_enabled()) {
|
2017-03-27 08:22:19 +03:00
|
|
|
/* to stop and start vmclock */
|
2017-01-27 15:24:58 +03:00
|
|
|
qemu_add_vm_change_state_handler(cpu_ppc_clock_vm_state_change,
|
|
|
|
&spapr->tb);
|
2017-03-27 08:22:19 +03:00
|
|
|
|
|
|
|
kvmppc_spapr_enable_inkernel_multitce();
|
2017-01-27 15:24:58 +03:00
|
|
|
}
|
2020-01-30 21:44:19 +03:00
|
|
|
|
2020-03-16 17:26:07 +03:00
|
|
|
qemu_cond_init(&spapr->fwnmi_machine_check_interlock_cond);
|
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 08:51:55 +03:00
|
|
|
if (spapr->vof) {
|
|
|
|
spapr->vof->fw_size = fw_size; /* for claim() on itself */
|
|
|
|
spapr_register_hypercall(KVMPPC_H_VOF_CLIENT, spapr_h_vof_client);
|
|
|
|
}
|
2022-06-22 08:10:08 +03:00
|
|
|
|
|
|
|
spapr_watchdog_init(spapr);
|
2011-04-01 08:15:20 +04:00
|
|
|
}
|
|
|
|
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
#define DEFAULT_KVM_TYPE "auto"
|
2019-03-04 13:13:33 +03:00
|
|
|
static int spapr_kvm_type(MachineState *machine, const char *vm_type)
|
2013-12-23 19:40:40 +04:00
|
|
|
{
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
/*
|
|
|
|
* The use of g_ascii_strcasecmp() for 'hv' and 'pr' is to
|
2023-07-14 14:18:16 +03:00
|
|
|
* accommodate the 'HV' and 'PV' formats that exists in the
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
* wild. The 'auto' mode is being introduced already as
|
|
|
|
* lower-case, thus we don't need to bother checking for
|
|
|
|
* "AUTO".
|
|
|
|
*/
|
|
|
|
if (!vm_type || !strcmp(vm_type, DEFAULT_KVM_TYPE)) {
|
2013-12-23 19:40:40 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
if (!g_ascii_strcasecmp(vm_type, "hv")) {
|
2013-12-23 19:40:40 +04:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
if (!g_ascii_strcasecmp(vm_type, "pr")) {
|
2013-12-23 19:40:40 +04:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
error_report("Unknown kvm-type specified '%s'", vm_type);
|
2023-08-22 19:31:03 +03:00
|
|
|
return -1;
|
2013-12-23 19:40:40 +04:00
|
|
|
}
|
|
|
|
|
2014-03-17 06:40:27 +04:00
|
|
|
/*
|
2015-01-19 06:45:12 +03:00
|
|
|
* Implementation of an interface to adjust firmware path
|
2014-03-17 06:40:27 +04:00
|
|
|
* for the bootindex property handling.
|
|
|
|
*/
|
|
|
|
static char *spapr_get_fw_dev_path(FWPathProvider *p, BusState *bus,
|
|
|
|
DeviceState *dev)
|
|
|
|
{
|
|
|
|
#define CAST(type, obj, name) \
|
|
|
|
((type *)object_dynamic_cast(OBJECT(obj), (name)))
|
|
|
|
SCSIDevice *d = CAST(SCSIDevice, dev, TYPE_SCSI_DEVICE);
|
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 07:35:37 +03:00
|
|
|
SpaprPhbState *phb = CAST(SpaprPhbState, dev, TYPE_SPAPR_PCI_HOST_BRIDGE);
|
2017-06-05 18:55:18 +03:00
|
|
|
VHostSCSICommon *vsc = CAST(VHostSCSICommon, dev, TYPE_VHOST_SCSI_COMMON);
|
spapr: Adjust firmware path of PCI devices
It is currently not possible to perform a strict boot from USB storage:
$ qemu-system-ppc64 -accel kvm -nodefaults -nographic -serial stdio \
-boot strict=on \
-device qemu-xhci \
-device usb-storage,drive=disk,bootindex=0 \
-blockdev driver=file,node-name=disk,filename=fedora-ppc64le.qcow2
SLOF **********************************************************************
QEMU Starting
Build Date = Jul 17 2020 11:15:24
FW Version = git-e18ddad8516ff2cf
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /pci@800000020000000
00 0000 (D) : 1b36 000d serial bus [ usb-xhci ]
No NVRAM common partition, re-initializing...
Scanning USB
XHCI: Initializing
USB Storage
SCSI: Looking for devices
101000000000000 DISK : "QEMU QEMU HARDDISK 2.5+"
Using default console: /vdevice/vty@71000000
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Trying to load: from: /pci@800000020000000/usb@0/storage@1/disk@101000000000000 ...
E3405: No such device
E3407: Load failed
Type 'boot' and press return to continue booting the system.
Type 'reset-all' and press return to reboot the system.
Ready!
0 >
The device tree handed over by QEMU to SLOF indeed contains:
qemu,boot-list =
"/pci@800000020000000/usb@0/storage@1/disk@101000000000000 HALT";
but the device node is named usb-xhci@0, not usb@0.
This happens because the firmware names of PCI devices returned
by get_boot_devices_list() come from pcibus_get_fw_dev_path(),
while the sPAPR PHB code uses a different naming scheme for
device nodes. This inconsistency has always been there but it was
hidden for a long time because SLOF used to rename USB device
nodes, until this commit, merged in QEMU 4.2.0 :
commit 85164ad4ed9960cac842fa4cc067c6b6699b0994
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date: Wed Sep 11 16:24:32 2019 +1000
pseries: Update SLOF firmware image
This fixes USB host bus adapter name in the device tree to match QEMU's
one.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fortunately, sPAPR implements the firmware path provider interface.
This provides a way to override the default firmware paths.
Just factor out the sPAPR PHB naming logic from spapr_dt_pci_device()
to a helper, and use it in the sPAPR firmware path provider hook.
Fixes: 85164ad4ed99 ("pseries: Update SLOF firmware image")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20210122170157.246374-1-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-22 20:01:57 +03:00
|
|
|
PCIDevice *pcidev = CAST(PCIDevice, dev, TYPE_PCI_DEVICE);
|
2014-03-17 06:40:27 +04:00
|
|
|
|
spapr.c: check bus != NULL in spapr_get_fw_dev_path()
spapr_get_fw_dev_path() is an impl of
FWPathProviderClass::get_dev_path(). This interface is used by
hw/core/qdev-fw.c via fw_path_provider_try_get_dev_path() in two
functions:
- static char *qdev_get_fw_dev_path_from_handler(), which is used only in
qdev_get_fw_dev_path_helper() and it's guarded by "if (dev &&
dev->parent_bus)";
- char *qdev_get_own_fw_dev_path_from_handler(), which is used in
softmmu/bootdevice.c in get_boot_device_path() like this:
if (dev) {
d = qdev_get_own_fw_dev_path_from_handler(dev->parent_bus, dev);
This means that, when called via softmmu/bootdevice.c, there's no check
of 'dev->parent_bus' being not NULL. The result is that the "BusState
*bus" arg of spapr_get_fw_dev_path() can potentially be NULL and if, at
the same time, "SCSIDevice *d" is not NULL, we'll hit this line:
void *spapr = CAST(void, bus->parent, "spapr-vscsi");
And we'll SIGINT because 'bus' is NULL and we're accessing bus->parent.
Adding a simple 'bus != NULL' check to guard the instances where we
access 'bus->parent' can avoid this altogether.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220121213852.30243-1-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-28 15:15:02 +03:00
|
|
|
if (d && bus) {
|
2014-03-17 06:40:27 +04:00
|
|
|
void *spapr = CAST(void, bus->parent, "spapr-vscsi");
|
|
|
|
VirtIOSCSI *virtio = CAST(VirtIOSCSI, bus->parent, TYPE_VIRTIO_SCSI);
|
|
|
|
USBDevice *usb = CAST(USBDevice, bus->parent, TYPE_USB_DEVICE);
|
|
|
|
|
|
|
|
if (spapr) {
|
|
|
|
/*
|
|
|
|
* Replace "channel@0/disk@0,0" with "disk@8000000000000000":
|
2019-01-09 17:03:23 +03:00
|
|
|
* In the top 16 bits of the 64-bit LUN, we use SRP luns of the form
|
|
|
|
* 0x8000 | (target << 8) | (bus << 5) | lun
|
|
|
|
* (see the "Logical unit addressing format" table in SAM5)
|
2014-03-17 06:40:27 +04:00
|
|
|
*/
|
2019-01-09 17:03:23 +03:00
|
|
|
unsigned id = 0x8000 | (d->id << 8) | (d->channel << 5) | d->lun;
|
2014-03-17 06:40:27 +04:00
|
|
|
return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev),
|
|
|
|
(uint64_t)id << 48);
|
|
|
|
} else if (virtio) {
|
|
|
|
/*
|
|
|
|
* We use SRP luns of the form 01000000 | (target << 8) | lun
|
|
|
|
* in the top 32 bits of the 64-bit LUN
|
|
|
|
* Note: the quote above is from SLOF and it is wrong,
|
|
|
|
* the actual binding is:
|
|
|
|
* swap 0100 or 10 << or 20 << ( target lun-id -- srplun )
|
|
|
|
*/
|
|
|
|
unsigned id = 0x1000000 | (d->id << 16) | d->lun;
|
2017-11-20 10:44:38 +03:00
|
|
|
if (d->lun >= 256) {
|
|
|
|
/* Use the LUN "flat space addressing method" */
|
|
|
|
id |= 0x4000;
|
|
|
|
}
|
2014-03-17 06:40:27 +04:00
|
|
|
return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev),
|
|
|
|
(uint64_t)id << 32);
|
|
|
|
} else if (usb) {
|
|
|
|
/*
|
|
|
|
* We use SRP luns of the form 01000000 | (usb-port << 16) | lun
|
|
|
|
* in the top 32 bits of the 64-bit LUN
|
|
|
|
*/
|
|
|
|
unsigned usb_port = atoi(usb->port->path);
|
|
|
|
unsigned id = 0x1000000 | (usb_port << 16) | d->lun;
|
|
|
|
return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev),
|
|
|
|
(uint64_t)id << 32);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
hw/ppc/spapr: Fix boot path of usb-host storage devices
When passing through an USB storage device to a pseries guest, it
is currently not possible to automatically boot from the device
if the "bootindex" property has been specified, too (e.g. when using
"-device nec-usb-xhci -device usb-host,hostbus=1,hostaddr=2,bootindex=0"
at the command line). The problem is that QEMU builds a device tree path
like "/pci@800000020000000/usb@0/usb-host@1" and passes it to SLOF
in the /chosen/qemu,boot-list property. SLOF, however, probes the
USB device, recognizes that it is a storage device and thus changes
its name to "storage", and additionally adds a child node for the
SCSI LUN, so the correct boot path in SLOF is something like
"/pci@800000020000000/usb@0/storage@1/disk@101000000000000" instead.
So when we detect an USB mass storage device with SCSI interface,
we've got to adjust the firmware boot-device path properly that
SLOF can automatically boot from the device.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1354177
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-12-15 00:44:17 +03:00
|
|
|
/*
|
|
|
|
* SLOF probes the USB devices, and if it recognizes that the device is a
|
|
|
|
* storage device, it changes its name to "storage" instead of "usb-host",
|
|
|
|
* and additionally adds a child node for the SCSI LUN, so the correct
|
|
|
|
* boot path in SLOF is something like .../storage@1/disk@xxx" instead.
|
|
|
|
*/
|
|
|
|
if (strcmp("usb-host", qdev_fw_name(dev)) == 0) {
|
|
|
|
USBDevice *usbdev = CAST(USBDevice, dev, TYPE_USB_DEVICE);
|
2021-06-24 13:38:33 +03:00
|
|
|
if (usb_device_is_scsi_storage(usbdev)) {
|
hw/ppc/spapr: Fix boot path of usb-host storage devices
When passing through an USB storage device to a pseries guest, it
is currently not possible to automatically boot from the device
if the "bootindex" property has been specified, too (e.g. when using
"-device nec-usb-xhci -device usb-host,hostbus=1,hostaddr=2,bootindex=0"
at the command line). The problem is that QEMU builds a device tree path
like "/pci@800000020000000/usb@0/usb-host@1" and passes it to SLOF
in the /chosen/qemu,boot-list property. SLOF, however, probes the
USB device, recognizes that it is a storage device and thus changes
its name to "storage", and additionally adds a child node for the
SCSI LUN, so the correct boot path in SLOF is something like
"/pci@800000020000000/usb@0/storage@1/disk@101000000000000" instead.
So when we detect an USB mass storage device with SCSI interface,
we've got to adjust the firmware boot-device path properly that
SLOF can automatically boot from the device.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1354177
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-12-15 00:44:17 +03:00
|
|
|
return g_strdup_printf("storage@%s/disk", usbdev->port->path);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-17 06:40:27 +04:00
|
|
|
if (phb) {
|
|
|
|
/* Replace "pci" with "pci@800000020000000" */
|
|
|
|
return g_strdup_printf("pci@%"PRIX64, phb->buid);
|
|
|
|
}
|
|
|
|
|
2017-06-05 18:55:18 +03:00
|
|
|
if (vsc) {
|
|
|
|
/* Same logic as virtio above */
|
|
|
|
unsigned id = 0x1000000 | (vsc->target << 16) | vsc->lun;
|
|
|
|
return g_strdup_printf("disk@%"PRIX64, (uint64_t)id << 32);
|
|
|
|
}
|
|
|
|
|
2017-06-07 11:20:27 +03:00
|
|
|
if (g_str_equal("pci-bridge", qdev_fw_name(dev))) {
|
|
|
|
/* SLOF uses "pci" instead of "pci-bridge" for PCI bridges */
|
2023-09-18 17:58:47 +03:00
|
|
|
PCIDevice *pdev = CAST(PCIDevice, dev, TYPE_PCI_DEVICE);
|
|
|
|
return g_strdup_printf("pci@%x", PCI_SLOT(pdev->devfn));
|
2017-06-07 11:20:27 +03:00
|
|
|
}
|
|
|
|
|
spapr: Adjust firmware path of PCI devices
It is currently not possible to perform a strict boot from USB storage:
$ qemu-system-ppc64 -accel kvm -nodefaults -nographic -serial stdio \
-boot strict=on \
-device qemu-xhci \
-device usb-storage,drive=disk,bootindex=0 \
-blockdev driver=file,node-name=disk,filename=fedora-ppc64le.qcow2
SLOF **********************************************************************
QEMU Starting
Build Date = Jul 17 2020 11:15:24
FW Version = git-e18ddad8516ff2cf
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /pci@800000020000000
00 0000 (D) : 1b36 000d serial bus [ usb-xhci ]
No NVRAM common partition, re-initializing...
Scanning USB
XHCI: Initializing
USB Storage
SCSI: Looking for devices
101000000000000 DISK : "QEMU QEMU HARDDISK 2.5+"
Using default console: /vdevice/vty@71000000
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Trying to load: from: /pci@800000020000000/usb@0/storage@1/disk@101000000000000 ...
E3405: No such device
E3407: Load failed
Type 'boot' and press return to continue booting the system.
Type 'reset-all' and press return to reboot the system.
Ready!
0 >
The device tree handed over by QEMU to SLOF indeed contains:
qemu,boot-list =
"/pci@800000020000000/usb@0/storage@1/disk@101000000000000 HALT";
but the device node is named usb-xhci@0, not usb@0.
This happens because the firmware names of PCI devices returned
by get_boot_devices_list() come from pcibus_get_fw_dev_path(),
while the sPAPR PHB code uses a different naming scheme for
device nodes. This inconsistency has always been there but it was
hidden for a long time because SLOF used to rename USB device
nodes, until this commit, merged in QEMU 4.2.0 :
commit 85164ad4ed9960cac842fa4cc067c6b6699b0994
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date: Wed Sep 11 16:24:32 2019 +1000
pseries: Update SLOF firmware image
This fixes USB host bus adapter name in the device tree to match QEMU's
one.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fortunately, sPAPR implements the firmware path provider interface.
This provides a way to override the default firmware paths.
Just factor out the sPAPR PHB naming logic from spapr_dt_pci_device()
to a helper, and use it in the sPAPR firmware path provider hook.
Fixes: 85164ad4ed99 ("pseries: Update SLOF firmware image")
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <20210122170157.246374-1-groug@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-22 20:01:57 +03:00
|
|
|
if (pcidev) {
|
|
|
|
return spapr_pci_fw_dev_name(pcidev);
|
|
|
|
}
|
|
|
|
|
2014-03-17 06:40:27 +04:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-05-31 01:24:32 +04:00
|
|
|
static char *spapr_get_kvm_type(Object *obj, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2014-05-31 01:24:32 +04:00
|
|
|
|
2015-07-02 09:23:04 +03:00
|
|
|
return g_strdup(spapr->kvm_type);
|
2014-05-31 01:24:32 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_kvm_type(Object *obj, const char *value, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2014-05-31 01:24:32 +04:00
|
|
|
|
2015-07-02 09:23:04 +03:00
|
|
|
g_free(spapr->kvm_type);
|
|
|
|
spapr->kvm_type = g_strdup(value);
|
2014-05-31 01:24:32 +04:00
|
|
|
}
|
|
|
|
|
spapr: add hotplug interrupt machine options
This adds machine options of the form:
-machine pseries,modern-hotplug-events=true
-machine pseries,modern-hotplug-events=false
If false, QEMU will force the use of "legacy" style hotplug events,
which are surfaced through EPOW events instead of a dedicated
hot plug event source, and lack certain features necessary, mainly,
for memory unplug support.
If true, QEMU will enable support for "modern" dedicated hot plug
event source. Note that we will still default to "legacy" style unless
the guest advertises support for the "modern" hotplug events via
ibm,client-architecture-support hcall during early boot.
For pseries-2.7 and earlier we default to false, for newer machine
types we default to true.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-27 05:20:27 +03:00
|
|
|
static bool spapr_get_modern_hotplug_events(Object *obj, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
spapr: add hotplug interrupt machine options
This adds machine options of the form:
-machine pseries,modern-hotplug-events=true
-machine pseries,modern-hotplug-events=false
If false, QEMU will force the use of "legacy" style hotplug events,
which are surfaced through EPOW events instead of a dedicated
hot plug event source, and lack certain features necessary, mainly,
for memory unplug support.
If true, QEMU will enable support for "modern" dedicated hot plug
event source. Note that we will still default to "legacy" style unless
the guest advertises support for the "modern" hotplug events via
ibm,client-architecture-support hcall during early boot.
For pseries-2.7 and earlier we default to false, for newer machine
types we default to true.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-27 05:20:27 +03:00
|
|
|
|
|
|
|
return spapr->use_hotplug_event_source;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_modern_hotplug_events(Object *obj, bool value,
|
|
|
|
Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
spapr: add hotplug interrupt machine options
This adds machine options of the form:
-machine pseries,modern-hotplug-events=true
-machine pseries,modern-hotplug-events=false
If false, QEMU will force the use of "legacy" style hotplug events,
which are surfaced through EPOW events instead of a dedicated
hot plug event source, and lack certain features necessary, mainly,
for memory unplug support.
If true, QEMU will enable support for "modern" dedicated hot plug
event source. Note that we will still default to "legacy" style unless
the guest advertises support for the "modern" hotplug events via
ibm,client-architecture-support hcall during early boot.
For pseries-2.7 and earlier we default to false, for newer machine
types we default to true.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-27 05:20:27 +03:00
|
|
|
|
|
|
|
spapr->use_hotplug_event_source = value;
|
|
|
|
}
|
|
|
|
|
2018-03-13 20:17:31 +03:00
|
|
|
static bool spapr_get_msix_emulation(Object *obj, Error **errp)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-05-12 08:46:11 +03:00
|
|
|
static char *spapr_get_resize_hpt(Object *obj, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2017-05-12 08:46:11 +03:00
|
|
|
|
|
|
|
switch (spapr->resize_hpt) {
|
|
|
|
case SPAPR_RESIZE_HPT_DEFAULT:
|
|
|
|
return g_strdup("default");
|
|
|
|
case SPAPR_RESIZE_HPT_DISABLED:
|
|
|
|
return g_strdup("disabled");
|
|
|
|
case SPAPR_RESIZE_HPT_ENABLED:
|
|
|
|
return g_strdup("enabled");
|
|
|
|
case SPAPR_RESIZE_HPT_REQUIRED:
|
|
|
|
return g_strdup("required");
|
|
|
|
}
|
|
|
|
g_assert_not_reached();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_resize_hpt(Object *obj, const char *value, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2017-05-12 08:46:11 +03:00
|
|
|
|
|
|
|
if (strcmp(value, "default") == 0) {
|
|
|
|
spapr->resize_hpt = SPAPR_RESIZE_HPT_DEFAULT;
|
|
|
|
} else if (strcmp(value, "disabled") == 0) {
|
|
|
|
spapr->resize_hpt = SPAPR_RESIZE_HPT_DISABLED;
|
|
|
|
} else if (strcmp(value, "enabled") == 0) {
|
|
|
|
spapr->resize_hpt = SPAPR_RESIZE_HPT_ENABLED;
|
|
|
|
} else if (strcmp(value, "required") == 0) {
|
|
|
|
spapr->resize_hpt = SPAPR_RESIZE_HPT_REQUIRED;
|
|
|
|
} else {
|
|
|
|
error_setg(errp, "Bad value for \"resize-hpt\" property");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 08:51:55 +03:00
|
|
|
static bool spapr_get_vof(Object *obj, Error **errp)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
|
|
|
|
|
|
|
return spapr->vof != NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_vof(Object *obj, bool value, Error **errp)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
|
|
|
|
|
|
|
if (spapr->vof) {
|
|
|
|
vof_cleanup(spapr->vof);
|
|
|
|
g_free(spapr->vof);
|
|
|
|
spapr->vof = NULL;
|
|
|
|
}
|
|
|
|
if (!value) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
spapr->vof = g_malloc0(sizeof(*spapr->vof));
|
|
|
|
}
|
|
|
|
|
2018-12-18 01:34:43 +03:00
|
|
|
static char *spapr_get_ic_mode(Object *obj, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-12-18 01:34:43 +03:00
|
|
|
|
|
|
|
if (spapr->irq == &spapr_irq_xics_legacy) {
|
|
|
|
return g_strdup("legacy");
|
|
|
|
} else if (spapr->irq == &spapr_irq_xics) {
|
|
|
|
return g_strdup("xics");
|
|
|
|
} else if (spapr->irq == &spapr_irq_xive) {
|
|
|
|
return g_strdup("xive");
|
2019-01-02 08:57:42 +03:00
|
|
|
} else if (spapr->irq == &spapr_irq_dual) {
|
|
|
|
return g_strdup("dual");
|
2018-12-18 01:34:43 +03:00
|
|
|
}
|
|
|
|
g_assert_not_reached();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_ic_mode(Object *obj, const char *value, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2018-12-18 01:34:43 +03:00
|
|
|
|
2019-01-17 14:06:38 +03:00
|
|
|
if (SPAPR_MACHINE_GET_CLASS(spapr)->legacy_irq_allocation) {
|
|
|
|
error_setg(errp, "This machine only uses the legacy XICS backend, don't pass ic-mode");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-12-18 01:34:43 +03:00
|
|
|
/* The legacy IRQ backend can not be set */
|
|
|
|
if (strcmp(value, "xics") == 0) {
|
|
|
|
spapr->irq = &spapr_irq_xics;
|
|
|
|
} else if (strcmp(value, "xive") == 0) {
|
|
|
|
spapr->irq = &spapr_irq_xive;
|
2019-01-02 08:57:42 +03:00
|
|
|
} else if (strcmp(value, "dual") == 0) {
|
|
|
|
spapr->irq = &spapr_irq_dual;
|
2018-12-18 01:34:43 +03:00
|
|
|
} else {
|
|
|
|
error_setg(errp, "Bad value for \"ic-mode\" property");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-18 21:13:49 +03:00
|
|
|
static char *spapr_get_host_model(Object *obj, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2019-02-18 21:13:49 +03:00
|
|
|
|
|
|
|
return g_strdup(spapr->host_model);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_host_model(Object *obj, const char *value, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2019-02-18 21:13:49 +03:00
|
|
|
|
|
|
|
g_free(spapr->host_model);
|
|
|
|
spapr->host_model = g_strdup(value);
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *spapr_get_host_serial(Object *obj, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2019-02-18 21:13:49 +03:00
|
|
|
|
|
|
|
return g_strdup(spapr->host_serial);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_set_host_serial(Object *obj, const char *value, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2019-02-18 21:13:49 +03:00
|
|
|
|
|
|
|
g_free(spapr->host_serial);
|
|
|
|
spapr->host_serial = g_strdup(value);
|
|
|
|
}
|
|
|
|
|
2017-12-08 04:47:34 +03:00
|
|
|
static void spapr_instance_init(Object *obj)
|
2014-05-31 01:24:32 +04: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
2020-12-08 19:46:06 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(ms);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NVDIMM support went live in 5.1 without considering that, in
|
|
|
|
* other archs, the user needs to enable NVDIMM support with the
|
|
|
|
* 'nvdimm' machine option and the default behavior is NVDIMM
|
|
|
|
* support disabled. It is too late to roll back to the standard
|
|
|
|
* behavior without breaking 5.1 guests.
|
|
|
|
*/
|
|
|
|
if (mc->nvdimm_supported) {
|
|
|
|
ms->nvdimms_state->is_enabled = true;
|
|
|
|
}
|
2016-02-09 02:28:58 +03:00
|
|
|
|
|
|
|
spapr->htab_fd = -1;
|
spapr: add hotplug interrupt machine options
This adds machine options of the form:
-machine pseries,modern-hotplug-events=true
-machine pseries,modern-hotplug-events=false
If false, QEMU will force the use of "legacy" style hotplug events,
which are surfaced through EPOW events instead of a dedicated
hot plug event source, and lack certain features necessary, mainly,
for memory unplug support.
If true, QEMU will enable support for "modern" dedicated hot plug
event source. Note that we will still default to "legacy" style unless
the guest advertises support for the "modern" hotplug events via
ibm,client-architecture-support hcall during early boot.
For pseries-2.7 and earlier we default to false, for newer machine
types we default to true.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-27 05:20:27 +03:00
|
|
|
spapr->use_hotplug_event_source = true;
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
spapr->kvm_type = g_strdup(DEFAULT_KVM_TYPE);
|
2014-05-31 01:24:32 +04:00
|
|
|
object_property_add_str(obj, "kvm-type",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_get_kvm_type, spapr_set_kvm_type);
|
2014-12-16 19:58:05 +03:00
|
|
|
object_property_set_description(obj, "kvm-type",
|
spapr.c: set a 'kvm-type' default value instead of relying on NULL
spapr_kvm_type() is considering 'vm_type=NULL' as a valid input, where
the function returns 0. This is relying on the current QEMU machine
options handling logic, where the absence of the 'kvm-type' option
will be reflected as 'vm_type=NULL' in this function.
This is not robust, and will break if QEMU options code decides to propagate
something else in the case mentioned above (e.g. an empty string instead
of NULL).
Let's avoid this entirely by setting a non-NULL default value in case of
no user input for 'kvm-type'. spapr_kvm_type() was changed to handle 3 fixed
values of kvm-type: "auto", "hv", and "pr", with "auto" being the default
if no kvm-type was set by the user. This allows us to always be predictable
regardless of any enhancements/changes made in QEMU options mechanics.
While we're at it, let's also document in 'kvm-type' description the
already existing default mode, now named 'auto'. The information provided
about it is based on how the pseries kernel handles the KVM_CREATE_VM
ioctl(), where the default value '0' makes the kernel choose an available
KVM module to use, giving precedence to kvm_hv. This logic is described in
the kernel source file arch/powerpc/kvm/powerpc.c, function kvm_arch_init_vm().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20201210145517.1532269-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2020-12-10 17:55:17 +03:00
|
|
|
"Specifies the KVM virtualization mode (auto,"
|
|
|
|
" hv, pr). Defaults to 'auto'. This mode will use"
|
|
|
|
" any available KVM module loaded in the host,"
|
|
|
|
" where kvm_hv takes precedence if both kvm_hv and"
|
|
|
|
" kvm_pr are loaded.");
|
spapr: add hotplug interrupt machine options
This adds machine options of the form:
-machine pseries,modern-hotplug-events=true
-machine pseries,modern-hotplug-events=false
If false, QEMU will force the use of "legacy" style hotplug events,
which are surfaced through EPOW events instead of a dedicated
hot plug event source, and lack certain features necessary, mainly,
for memory unplug support.
If true, QEMU will enable support for "modern" dedicated hot plug
event source. Note that we will still default to "legacy" style unless
the guest advertises support for the "modern" hotplug events via
ibm,client-architecture-support hcall during early boot.
For pseries-2.7 and earlier we default to false, for newer machine
types we default to true.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-27 05:20:27 +03:00
|
|
|
object_property_add_bool(obj, "modern-hotplug-events",
|
|
|
|
spapr_get_modern_hotplug_events,
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_set_modern_hotplug_events);
|
spapr: add hotplug interrupt machine options
This adds machine options of the form:
-machine pseries,modern-hotplug-events=true
-machine pseries,modern-hotplug-events=false
If false, QEMU will force the use of "legacy" style hotplug events,
which are surfaced through EPOW events instead of a dedicated
hot plug event source, and lack certain features necessary, mainly,
for memory unplug support.
If true, QEMU will enable support for "modern" dedicated hot plug
event source. Note that we will still default to "legacy" style unless
the guest advertises support for the "modern" hotplug events via
ibm,client-architecture-support hcall during early boot.
For pseries-2.7 and earlier we default to false, for newer machine
types we default to true.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-27 05:20:27 +03:00
|
|
|
object_property_set_description(obj, "modern-hotplug-events",
|
|
|
|
"Use dedicated hotplug event mechanism in"
|
|
|
|
" place of standard EPOW events when possible"
|
2020-05-05 18:29:15 +03:00
|
|
|
" (required for memory hot-unplug support)");
|
2017-06-11 15:33:59 +03:00
|
|
|
ppc_compat_add_property(obj, "max-cpu-compat", &spapr->max_compat_pvr,
|
2020-05-05 18:29:23 +03:00
|
|
|
"Maximum permitted CPU compatibility mode");
|
2017-05-12 08:46:11 +03:00
|
|
|
|
|
|
|
object_property_add_str(obj, "resize-hpt",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_get_resize_hpt, spapr_set_resize_hpt);
|
2017-05-12 08:46:11 +03:00
|
|
|
object_property_set_description(obj, "resize-hpt",
|
2020-05-05 18:29:15 +03:00
|
|
|
"Resizing of the Hash Page Table (enabled, disabled, required)");
|
2020-02-04 16:16:01 +03:00
|
|
|
object_property_add_uint32_ptr(obj, "vsmt",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
&spapr->vsmt, OBJ_PROP_FLAG_READWRITE);
|
2017-08-18 08:50:22 +03:00
|
|
|
object_property_set_description(obj, "vsmt",
|
|
|
|
"Virtual SMT: KVM behaves as if this were"
|
2020-05-05 18:29:15 +03:00
|
|
|
" the host's SMT mode");
|
2020-02-04 16:16:01 +03:00
|
|
|
|
2018-03-13 20:17:31 +03:00
|
|
|
object_property_add_bool(obj, "vfio-no-msix-emulation",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_get_msix_emulation, NULL);
|
2018-12-18 01:34:43 +03:00
|
|
|
|
2020-02-04 16:16:01 +03:00
|
|
|
object_property_add_uint64_ptr(obj, "kernel-addr",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
&spapr->kernel_addr, OBJ_PROP_FLAG_READWRITE);
|
2020-02-03 06:29:42 +03:00
|
|
|
object_property_set_description(obj, "kernel-addr",
|
|
|
|
stringify(KERNEL_LOAD_ADDR)
|
2020-05-05 18:29:15 +03:00
|
|
|
" for -kernel is the default");
|
2020-02-03 06:29:42 +03:00
|
|
|
spapr->kernel_addr = KERNEL_LOAD_ADDR;
|
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 08:51:55 +03:00
|
|
|
|
|
|
|
object_property_add_bool(obj, "x-vof", spapr_get_vof, spapr_set_vof);
|
|
|
|
object_property_set_description(obj, "x-vof",
|
|
|
|
"Enable Virtual Open Firmware (experimental)");
|
|
|
|
|
2018-12-18 01:34:43 +03:00
|
|
|
/* The machine class defines the default interrupt controller mode */
|
|
|
|
spapr->irq = smc->irq;
|
|
|
|
object_property_add_str(obj, "ic-mode", spapr_get_ic_mode,
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_set_ic_mode);
|
2018-12-18 01:34:43 +03:00
|
|
|
object_property_set_description(obj, "ic-mode",
|
2020-05-05 18:29:15 +03:00
|
|
|
"Specifies the interrupt controller mode (xics, xive, dual)");
|
2019-02-18 21:13:49 +03:00
|
|
|
|
|
|
|
object_property_add_str(obj, "host-model",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_get_host_model, spapr_set_host_model);
|
2019-02-18 21:13:49 +03:00
|
|
|
object_property_set_description(obj, "host-model",
|
2020-05-05 18:29:15 +03:00
|
|
|
"Host model to advertise in guest device tree");
|
2019-02-18 21:13:49 +03:00
|
|
|
object_property_add_str(obj, "host-serial",
|
qom: Drop parameter @errp of object_property_add() & friends
The only way object_property_add() can fail is when a property with
the same name already exists. Since our property names are all
hardcoded, failure is a programming error, and the appropriate way to
handle it is passing &error_abort.
Same for its variants, except for object_property_add_child(), which
additionally fails when the child already has a parent. Parentage is
also under program control, so this is a programming error, too.
We have a bit over 500 callers. Almost half of them pass
&error_abort, slightly fewer ignore errors, one test case handles
errors, and the remaining few callers pass them to their own callers.
The previous few commits demonstrated once again that ignoring
programming errors is a bad idea.
Of the few ones that pass on errors, several violate the Error API.
The Error ** argument must be NULL, &error_abort, &error_fatal, or a
pointer to a variable containing NULL. Passing an argument of the
latter kind twice without clearing it in between is wrong: if the
first call sets an error, it no longer points to NULL for the second
call. ich9_pm_add_properties(), sparc32_ledma_realize(),
sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
are wrong that way.
When the one appropriate choice of argument is &error_abort, letting
users pick the argument is a bad idea.
Drop parameter @errp and assert the preconditions instead.
There's one exception to "duplicate property name is a programming
error": the way object_property_add() implements the magic (and
undocumented) "automatic arrayification". Don't drop @errp there.
Instead, rename object_property_add() to object_property_try_add(),
and add the obvious wrapper object_property_add().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200505152926.18877-15-armbru@redhat.com>
[Two semantic rebase conflicts resolved]
2020-05-05 18:29:22 +03:00
|
|
|
spapr_get_host_serial, spapr_set_host_serial);
|
2019-02-18 21:13:49 +03:00
|
|
|
object_property_set_description(obj, "host-serial",
|
2020-05-05 18:29:15 +03:00
|
|
|
"Host serial number to advertise in guest device tree");
|
2014-05-31 01:24:32 +04:00
|
|
|
}
|
|
|
|
|
2015-12-28 09:38:26 +03:00
|
|
|
static void spapr_machine_finalizefn(Object *obj)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2015-12-28 09:38:26 +03:00
|
|
|
|
|
|
|
g_free(spapr->kvm_type);
|
|
|
|
}
|
|
|
|
|
2016-12-05 08:50:21 +03:00
|
|
|
void spapr_do_system_reset_on_cpu(CPUState *cs, run_on_cpu_data arg)
|
2014-08-20 16:16:36 +04:00
|
|
|
{
|
2020-03-16 17:26:12 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
|
2020-03-25 17:41:43 +03:00
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
CPUPPCState *env = &cpu->env;
|
2020-03-16 17:26:12 +03:00
|
|
|
|
2014-08-20 16:16:36 +04:00
|
|
|
cpu_synchronize_state(cs);
|
2020-03-16 17:26:12 +03:00
|
|
|
/* If FWNMI is inactive, addr will be -1, which will deliver to 0x100 */
|
|
|
|
if (spapr->fwnmi_system_reset_addr != -1) {
|
|
|
|
uint64_t rtas_addr, addr;
|
|
|
|
|
|
|
|
/* get rtas addr from fdt */
|
|
|
|
rtas_addr = spapr_get_rtas_addr();
|
|
|
|
if (!rtas_addr) {
|
|
|
|
qemu_system_guest_panicked(NULL);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
addr = rtas_addr + RTAS_ERROR_LOG_MAX + cs->cpu_index * sizeof(uint64_t)*2;
|
|
|
|
stq_be_phys(&address_space_memory, addr, env->gpr[3]);
|
|
|
|
stq_be_phys(&address_space_memory, addr + sizeof(uint64_t), 0);
|
|
|
|
env->gpr[3] = addr;
|
|
|
|
}
|
2020-03-25 17:41:43 +03:00
|
|
|
ppc_cpu_do_system_reset(cs);
|
|
|
|
if (spapr->fwnmi_system_reset_addr != -1) {
|
|
|
|
env->nip = spapr->fwnmi_system_reset_addr;
|
|
|
|
}
|
2014-08-20 16:16:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_nmi(NMIState *n, int cpu_index, Error **errp)
|
|
|
|
{
|
|
|
|
CPUState *cs;
|
|
|
|
|
|
|
|
CPU_FOREACH(cs) {
|
2016-12-05 08:50:21 +03:00
|
|
|
async_run_on_cpu(cs, spapr_do_system_reset_on_cpu, RUN_ON_CPU_NULL);
|
2014-08-20 16:16:36 +04: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 07:35:37 +03:00
|
|
|
int spapr_lmb_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr,
|
2019-02-19 20:17:43 +03:00
|
|
|
void *fdt, int *fdt_start_offset, Error **errp)
|
|
|
|
{
|
|
|
|
uint64_t addr;
|
|
|
|
uint32_t node;
|
|
|
|
|
|
|
|
addr = spapr_drc_index(drc) * SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
node = object_property_get_uint(OBJECT(drc->dev), PC_DIMM_NODE_PROP,
|
|
|
|
&error_abort);
|
spapr: introduce SpaprMachineState::numa_assoc_array
The next step to centralize all NUMA/associativity handling in
the spapr machine is to create a 'one stop place' for all
things ibm,associativity.
This patch introduces numa_assoc_array, a 2 dimensional array
that will store all ibm,associativity arrays of all NUMA nodes.
This array is initialized in a new spapr_numa_associativity_init()
function, called in spapr_machine_init(). It is being initialized
with the same values used in other ibm,associativity properties
around spapr files (i.e. all zeros, last value is node_id).
The idea is to remove all hardcoded definitions and FDT writes
of ibm,associativity arrays, doing instead a call to the new
helper spapr_numa_write_associativity_dt() helper, that will
be able to write the DT with the correct values.
We'll start small, handling the trivial cases first. The
remaining instances of ibm,associativity will be handled
next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200903220639.563090-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-09-04 01:06:33 +03:00
|
|
|
*fdt_start_offset = spapr_dt_memory_node(spapr, fdt, node, addr,
|
2020-01-22 08:15:43 +03:00
|
|
|
SPAPR_MEMORY_BLOCK_SIZE);
|
2019-02-19 20:17:43 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:01 +03:00
|
|
|
static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size,
|
|
|
|
bool dedicated_hp_event_source)
|
2015-09-01 04:22:35 +03: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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2015-09-01 04:22:35 +03:00
|
|
|
uint32_t nr_lmbs = size/SPAPR_MEMORY_BLOCK_SIZE;
|
2019-02-19 20:17:43 +03:00
|
|
|
int i;
|
2016-10-27 05:20:29 +03:00
|
|
|
uint64_t addr = addr_start;
|
spapr: Treat devices added before inbound migration as coldplugged
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence. However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.
If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.
In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.
In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.
To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management. We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).
This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-09 14:08:10 +03:00
|
|
|
bool hotplugged = spapr_drc_hotplugged(dev);
|
2015-09-01 04:22:35 +03:00
|
|
|
|
|
|
|
for (i = 0; i < nr_lmbs; i++) {
|
2017-06-04 13:26:03 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr / SPAPR_MEMORY_BLOCK_SIZE);
|
2015-09-01 04:22:35 +03:00
|
|
|
g_assert(drc);
|
|
|
|
|
2020-11-21 02:42:01 +03:00
|
|
|
/*
|
|
|
|
* memory_device_get_free_addr() provided a range of free addresses
|
|
|
|
* that doesn't overlap with any existing mapping at pre-plug. The
|
|
|
|
* corresponding LMB DRCs are thus assumed to be all attachable.
|
|
|
|
*/
|
2020-12-01 14:37:28 +03:00
|
|
|
spapr_drc_attach(drc, dev);
|
spapr: Treat devices added before inbound migration as coldplugged
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence. However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.
If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.
In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.
In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.
To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management. We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).
This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-09 14:08:10 +03:00
|
|
|
if (!hotplugged) {
|
|
|
|
spapr_drc_reset(drc);
|
|
|
|
}
|
2015-09-01 04:22:35 +03:00
|
|
|
addr += SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
}
|
2016-05-24 20:55:04 +03:00
|
|
|
/* send hotplug notification to the
|
|
|
|
* guest only in case of hotplugged memory
|
|
|
|
*/
|
spapr: Treat devices added before inbound migration as coldplugged
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence. However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.
If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.
In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.
In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.
To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management. We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).
This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-09 14:08:10 +03:00
|
|
|
if (hotplugged) {
|
2016-10-27 05:20:29 +03:00
|
|
|
if (dedicated_hp_event_source) {
|
2017-06-04 13:26:03 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr_start / SPAPR_MEMORY_BLOCK_SIZE);
|
2020-12-15 20:36:51 +03:00
|
|
|
g_assert(drc);
|
2016-10-27 05:20:29 +03:00
|
|
|
spapr_hotplug_req_add_by_count_indexed(SPAPR_DR_CONNECTOR_TYPE_LMB,
|
|
|
|
nr_lmbs,
|
2017-06-02 06:49:20 +03:00
|
|
|
spapr_drc_index(drc));
|
2016-10-27 05:20:29 +03:00
|
|
|
} else {
|
|
|
|
spapr_hotplug_req_add_by_count(SPAPR_DR_CONNECTOR_TYPE_LMB,
|
|
|
|
nr_lmbs);
|
|
|
|
}
|
2016-05-24 20:55:04 +03:00
|
|
|
}
|
2015-09-01 04:22:35 +03:00
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:01 +03:00
|
|
|
static void spapr_memory_plug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
2015-09-01 04:22:35 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *ms = SPAPR_MACHINE(hotplug_dev);
|
2015-09-01 04:22:35 +03:00
|
|
|
PCDIMMDevice *dimm = PC_DIMM(dev);
|
2020-10-19 11:48:27 +03:00
|
|
|
uint64_t size, addr;
|
|
|
|
int64_t slot;
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
|
2017-08-21 09:30:29 +03:00
|
|
|
|
2018-10-05 12:20:17 +03:00
|
|
|
size = memory_device_get_region_size(MEMORY_DEVICE(dev), &error_abort);
|
2017-02-15 12:21:44 +03:00
|
|
|
|
2020-10-19 11:48:04 +03:00
|
|
|
pc_dimm_plug(dimm, MACHINE(ms));
|
2015-09-01 04:22:35 +03:00
|
|
|
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
if (!is_nvdimm) {
|
|
|
|
addr = object_property_get_uint(OBJECT(dimm),
|
2020-10-19 11:48:41 +03:00
|
|
|
PC_DIMM_ADDR_PROP, &error_abort);
|
2020-11-21 02:42:01 +03:00
|
|
|
spapr_add_lmbs(dev, addr, size,
|
|
|
|
spapr_ovec_test(ms->ov5_cas, OV5_HP_EVT));
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
} else {
|
2020-10-19 11:48:27 +03:00
|
|
|
slot = object_property_get_int(OBJECT(dimm),
|
2020-10-19 11:48:41 +03:00
|
|
|
PC_DIMM_SLOT_PROP, &error_abort);
|
2020-10-19 11:48:27 +03:00
|
|
|
/* We should have valid slot number at this point */
|
|
|
|
g_assert(slot >= 0);
|
2020-11-21 02:42:01 +03:00
|
|
|
spapr_add_nvdimm(dev, slot);
|
2017-07-03 17:54:36 +03:00
|
|
|
}
|
2015-09-01 04:22:35 +03:00
|
|
|
}
|
|
|
|
|
2017-05-23 14:18:09 +03:00
|
|
|
static void spapr_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
|
|
|
|
Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
const SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(hotplug_dev);
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev);
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
|
2017-05-23 14:18:09 +03:00
|
|
|
PCDIMMDevice *dimm = PC_DIMM(dev);
|
2018-08-01 16:34:41 +03:00
|
|
|
Error *local_err = NULL;
|
2017-08-21 09:30:29 +03:00
|
|
|
uint64_t size;
|
2018-04-18 07:21:45 +03:00
|
|
|
Object *memdev;
|
|
|
|
hwaddr pagesize;
|
2017-05-23 14:18:09 +03:00
|
|
|
|
2018-06-08 15:48:13 +03:00
|
|
|
if (!smc->dr_lmb_enabled) {
|
|
|
|
error_setg(errp, "Memory hotplug not supported for this machine");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:20:17 +03:00
|
|
|
size = memory_device_get_region_size(MEMORY_DEVICE(dimm), &local_err);
|
|
|
|
if (local_err) {
|
|
|
|
error_propagate(errp, local_err);
|
2017-08-21 09:30:29 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-08-26 00:57:48 +03:00
|
|
|
if (is_nvdimm) {
|
2020-09-14 15:35:02 +03:00
|
|
|
if (!spapr_nvdimm_validate(hotplug_dev, NVDIMM(dev), size, errp)) {
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
return;
|
|
|
|
}
|
2020-08-26 00:57:48 +03:00
|
|
|
} else if (size % SPAPR_MEMORY_BLOCK_SIZE) {
|
|
|
|
error_setg(errp, "Hotplugged memory size must be a multiple of "
|
|
|
|
"%" PRIu64 " MB", SPAPR_MEMORY_BLOCK_SIZE / MiB);
|
|
|
|
return;
|
2017-05-23 14:18:09 +03:00
|
|
|
}
|
|
|
|
|
2018-04-18 07:21:45 +03:00
|
|
|
memdev = object_property_get_link(OBJECT(dimm), PC_DIMM_MEMDEV_PROP,
|
|
|
|
&error_abort);
|
|
|
|
pagesize = host_memory_backend_pagesize(MEMORY_BACKEND(memdev));
|
2020-09-14 15:35:03 +03:00
|
|
|
if (!spapr_check_pagesize(spapr, pagesize, errp)) {
|
2018-08-01 16:34:41 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-10-05 12:20:12 +03:00
|
|
|
pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), NULL, errp);
|
2017-05-23 14:18:09 +03: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 07:35:37 +03:00
|
|
|
struct SpaprDimmState {
|
2017-05-24 10:01:48 +03:00
|
|
|
PCDIMMDevice *dimm;
|
2016-10-27 05:20:30 +03:00
|
|
|
uint32_t nr_lmbs;
|
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 07:35:37 +03:00
|
|
|
QTAILQ_ENTRY(SpaprDimmState) next;
|
2017-05-24 10:01:48 +03: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 07:35:37 +03:00
|
|
|
static SpaprDimmState *spapr_pending_dimm_unplugs_find(SpaprMachineState *s,
|
2017-05-24 10:01:48 +03:00
|
|
|
PCDIMMDevice *dimm)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprDimmState *dimm_state = NULL;
|
2017-05-24 10:01:48 +03:00
|
|
|
|
|
|
|
QTAILQ_FOREACH(dimm_state, &s->pending_dimm_unplugs, next) {
|
|
|
|
if (dimm_state->dimm == dimm) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return dimm_state;
|
|
|
|
}
|
|
|
|
|
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 07:35:37 +03:00
|
|
|
static SpaprDimmState *spapr_pending_dimm_unplugs_add(SpaprMachineState *spapr,
|
2017-07-21 07:51:06 +03:00
|
|
|
uint32_t nr_lmbs,
|
|
|
|
PCDIMMDevice *dimm)
|
2017-05-24 10:01:48 +03: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 07:35:37 +03:00
|
|
|
SpaprDimmState *ds = NULL;
|
2017-07-21 07:51:06 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If this request is for a DIMM whose removal had failed earlier
|
|
|
|
* (due to guest's refusal to remove the LMBs), we would have this
|
|
|
|
* dimm already in the pending_dimm_unplugs list. In that
|
|
|
|
* case don't add again.
|
|
|
|
*/
|
|
|
|
ds = spapr_pending_dimm_unplugs_find(spapr, dimm);
|
|
|
|
if (!ds) {
|
2022-03-15 17:41:56 +03:00
|
|
|
ds = g_new0(SpaprDimmState, 1);
|
2017-07-21 07:51:06 +03:00
|
|
|
ds->nr_lmbs = nr_lmbs;
|
|
|
|
ds->dimm = dimm;
|
|
|
|
QTAILQ_INSERT_HEAD(&spapr->pending_dimm_unplugs, ds, next);
|
|
|
|
}
|
|
|
|
return ds;
|
2017-05-24 10:01:48 +03: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 07:35:37 +03:00
|
|
|
static void spapr_pending_dimm_unplugs_remove(SpaprMachineState *spapr,
|
|
|
|
SpaprDimmState *dimm_state)
|
2017-05-24 10:01:48 +03:00
|
|
|
{
|
|
|
|
QTAILQ_REMOVE(&spapr->pending_dimm_unplugs, dimm_state, next);
|
|
|
|
g_free(dimm_state);
|
|
|
|
}
|
2016-10-27 05:20:30 +03: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 07:35:37 +03:00
|
|
|
static SpaprDimmState *spapr_recover_pending_dimm_state(SpaprMachineState *ms,
|
2017-05-22 22:35:50 +03:00
|
|
|
PCDIMMDevice *dimm)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2018-10-05 12:20:17 +03:00
|
|
|
uint64_t size = memory_device_get_region_size(MEMORY_DEVICE(dimm),
|
|
|
|
&error_abort);
|
2017-05-22 22:35:50 +03:00
|
|
|
uint32_t nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
uint32_t avail_lmbs = 0;
|
|
|
|
uint64_t addr_start, addr;
|
|
|
|
int i;
|
|
|
|
|
2020-10-19 11:48:16 +03:00
|
|
|
addr_start = object_property_get_uint(OBJECT(dimm), PC_DIMM_ADDR_PROP,
|
|
|
|
&error_abort);
|
2017-05-22 22:35:50 +03:00
|
|
|
|
|
|
|
addr = addr_start;
|
|
|
|
for (i = 0; i < nr_lmbs; i++) {
|
2017-06-04 13:26:03 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr / SPAPR_MEMORY_BLOCK_SIZE);
|
2017-05-22 22:35:50 +03:00
|
|
|
g_assert(drc);
|
2017-06-06 10:01:21 +03:00
|
|
|
if (drc->dev) {
|
2017-05-22 22:35:50 +03:00
|
|
|
avail_lmbs++;
|
|
|
|
}
|
|
|
|
addr += SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
}
|
|
|
|
|
2017-07-21 07:51:06 +03:00
|
|
|
return spapr_pending_dimm_unplugs_add(ms, avail_lmbs, dimm);
|
2017-05-22 22:35:50 +03:00
|
|
|
}
|
|
|
|
|
2021-03-02 17:10:19 +03:00
|
|
|
void spapr_memory_unplug_rollback(SpaprMachineState *spapr, DeviceState *dev)
|
spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state
Handling errors in memory hotunplug in the pSeries machine is more
complex than any other device type, because there are all the
complications that other devices has, and more.
For instance, determining a timeout for a DIMM hotunplug must consider
if it's a Hash-MMU or a Radix-MMU guest, because Hash guests takes
longer to hotunplug DIMMs. The size of the DIMM is also a factor, given
that longer DIMMs naturally takes longer to be hotunplugged from the
kernel. And there's also the guest memory usage to be considered: if
there's a process that is consuming memory that would be lost by the
DIMM unplug, the kernel will postpone the unplug process until the
process finishes, and then initiate the regular hotunplug process. The
first two considerations are manageable, but the last one is a deal
breaker.
There is no sane way for the pSeries machine to determine the memory
load in the guest when attempting a DIMM hotunplug - and even if there
was a way, the guest can start using all the RAM in the middle of the
unplug process and invalidate our previous assumptions - and in result
we can't even begin to calculate a timeout for the operation. This means
that we can't implement a viable timeout mechanism for memory unplug in
pSeries.
Going back to why we would consider an unplug timeout, the reason is
that we can't know if the kernel is giving up the unplug. Turns out
that, sometimes, we can. Consider a failed memory hotunplug attempt
where the kernel will error out with the following message:
'pseries-hotplug-mem: Memory indexed-count-remove failed, adding any
removed LMBs'
This happens when there is a LMB that the kernel gave up in removing,
and the LMBs previously marked for removal are now being added back.
This happens in the pseries kernel in [1], dlpar_memory_remove_by_ic()
into dlpar_add_lmb(), and after that update_lmb_associativity_index().
In this function, the kernel is configuring the LMB DRC connector again.
Note that this is a valid usage in LOPAR, as stated in section
"ibm,configure-connector RTAS Call":
'A subsequent sequence of calls to ibm,configure-connector with the same
entry from the “ibm,drc-indexes” or “ibm,drc-info” property will restart
the configuration of devices which were not completely configured.'
We can use this kernel behavior in our favor. If a DRC connector
reconfiguration for a LMB that we marked as unplug pending happens, this
indicates that the kernel changed its mind about the unplug and is
reasserting that it will keep using all the LMBs of the DIMM. In this
case, it's safe to assume that the whole DIMM device unplug was
cancelled.
This patch hops into rtas_ibm_configure_connector() and, in the scenario
described above, clear the unplug state for the DIMM device. This will
not solve all the problems we still have with memory unplug, but it will
cover this case where the kernel reconfigures LMBs after a failed
unplug. We are a bit more resilient, without using an unreliable
timeout, and we didn't make the remaining error cases any worse.
[1] arch/powerpc/platforms/pseries/hotplug-memory.c
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-6-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-22 22:45:31 +03:00
|
|
|
{
|
|
|
|
SpaprDimmState *ds;
|
|
|
|
PCDIMMDevice *dimm;
|
|
|
|
SpaprDrc *drc;
|
|
|
|
uint32_t nr_lmbs;
|
|
|
|
uint64_t size, addr_start, addr;
|
2021-03-02 17:10:19 +03:00
|
|
|
g_autofree char *qapi_error = NULL;
|
spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state
Handling errors in memory hotunplug in the pSeries machine is more
complex than any other device type, because there are all the
complications that other devices has, and more.
For instance, determining a timeout for a DIMM hotunplug must consider
if it's a Hash-MMU or a Radix-MMU guest, because Hash guests takes
longer to hotunplug DIMMs. The size of the DIMM is also a factor, given
that longer DIMMs naturally takes longer to be hotunplugged from the
kernel. And there's also the guest memory usage to be considered: if
there's a process that is consuming memory that would be lost by the
DIMM unplug, the kernel will postpone the unplug process until the
process finishes, and then initiate the regular hotunplug process. The
first two considerations are manageable, but the last one is a deal
breaker.
There is no sane way for the pSeries machine to determine the memory
load in the guest when attempting a DIMM hotunplug - and even if there
was a way, the guest can start using all the RAM in the middle of the
unplug process and invalidate our previous assumptions - and in result
we can't even begin to calculate a timeout for the operation. This means
that we can't implement a viable timeout mechanism for memory unplug in
pSeries.
Going back to why we would consider an unplug timeout, the reason is
that we can't know if the kernel is giving up the unplug. Turns out
that, sometimes, we can. Consider a failed memory hotunplug attempt
where the kernel will error out with the following message:
'pseries-hotplug-mem: Memory indexed-count-remove failed, adding any
removed LMBs'
This happens when there is a LMB that the kernel gave up in removing,
and the LMBs previously marked for removal are now being added back.
This happens in the pseries kernel in [1], dlpar_memory_remove_by_ic()
into dlpar_add_lmb(), and after that update_lmb_associativity_index().
In this function, the kernel is configuring the LMB DRC connector again.
Note that this is a valid usage in LOPAR, as stated in section
"ibm,configure-connector RTAS Call":
'A subsequent sequence of calls to ibm,configure-connector with the same
entry from the “ibm,drc-indexes” or “ibm,drc-info” property will restart
the configuration of devices which were not completely configured.'
We can use this kernel behavior in our favor. If a DRC connector
reconfiguration for a LMB that we marked as unplug pending happens, this
indicates that the kernel changed its mind about the unplug and is
reasserting that it will keep using all the LMBs of the DIMM. In this
case, it's safe to assume that the whole DIMM device unplug was
cancelled.
This patch hops into rtas_ibm_configure_connector() and, in the scenario
described above, clear the unplug state for the DIMM device. This will
not solve all the problems we still have with memory unplug, but it will
cover this case where the kernel reconfigures LMBs after a failed
unplug. We are a bit more resilient, without using an unreliable
timeout, and we didn't make the remaining error cases any worse.
[1] arch/powerpc/platforms/pseries/hotplug-memory.c
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-6-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-22 22:45:31 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!dev) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dimm = PC_DIMM(dev);
|
|
|
|
ds = spapr_pending_dimm_unplugs_find(spapr, dimm);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 'ds == NULL' would mean that the DIMM doesn't have a pending
|
|
|
|
* unplug state, but one of its DRC is marked as unplug_requested.
|
|
|
|
* This is bad and weird enough to g_assert() out.
|
|
|
|
*/
|
|
|
|
g_assert(ds);
|
|
|
|
|
|
|
|
spapr_pending_dimm_unplugs_remove(spapr, ds);
|
|
|
|
|
|
|
|
size = memory_device_get_region_size(MEMORY_DEVICE(dimm), &error_abort);
|
|
|
|
nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
|
|
|
|
addr_start = object_property_get_uint(OBJECT(dimm), PC_DIMM_ADDR_PROP,
|
|
|
|
&error_abort);
|
|
|
|
|
|
|
|
addr = addr_start;
|
|
|
|
for (i = 0; i < nr_lmbs; i++) {
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr / SPAPR_MEMORY_BLOCK_SIZE);
|
|
|
|
g_assert(drc);
|
|
|
|
|
|
|
|
drc->unplug_requested = false;
|
|
|
|
addr += SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
}
|
2021-03-02 17:10:19 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Tell QAPI that something happened and the memory
|
2021-09-07 03:47:54 +03:00
|
|
|
* hotunplug wasn't successful. Keep sending
|
|
|
|
* MEM_UNPLUG_ERROR even while sending
|
|
|
|
* DEVICE_UNPLUG_GUEST_ERROR until the deprecation of
|
|
|
|
* MEM_UNPLUG_ERROR is due.
|
2021-03-02 17:10:19 +03:00
|
|
|
*/
|
|
|
|
qapi_error = g_strdup_printf("Memory hotunplug rejected by the guest "
|
|
|
|
"for device %s", dev->id);
|
2021-09-07 03:47:54 +03:00
|
|
|
|
2021-09-07 03:47:50 +03:00
|
|
|
qapi_event_send_mem_unplug_error(dev->id ? : "", qapi_error);
|
2021-09-07 03:47:54 +03:00
|
|
|
|
2022-11-04 19:07:02 +03:00
|
|
|
qapi_event_send_device_unplug_guest_error(dev->id,
|
2021-09-07 03:47:54 +03:00
|
|
|
dev->canonical_path);
|
spapr_drc.c: use DRC reconfiguration to cleanup DIMM unplug state
Handling errors in memory hotunplug in the pSeries machine is more
complex than any other device type, because there are all the
complications that other devices has, and more.
For instance, determining a timeout for a DIMM hotunplug must consider
if it's a Hash-MMU or a Radix-MMU guest, because Hash guests takes
longer to hotunplug DIMMs. The size of the DIMM is also a factor, given
that longer DIMMs naturally takes longer to be hotunplugged from the
kernel. And there's also the guest memory usage to be considered: if
there's a process that is consuming memory that would be lost by the
DIMM unplug, the kernel will postpone the unplug process until the
process finishes, and then initiate the regular hotunplug process. The
first two considerations are manageable, but the last one is a deal
breaker.
There is no sane way for the pSeries machine to determine the memory
load in the guest when attempting a DIMM hotunplug - and even if there
was a way, the guest can start using all the RAM in the middle of the
unplug process and invalidate our previous assumptions - and in result
we can't even begin to calculate a timeout for the operation. This means
that we can't implement a viable timeout mechanism for memory unplug in
pSeries.
Going back to why we would consider an unplug timeout, the reason is
that we can't know if the kernel is giving up the unplug. Turns out
that, sometimes, we can. Consider a failed memory hotunplug attempt
where the kernel will error out with the following message:
'pseries-hotplug-mem: Memory indexed-count-remove failed, adding any
removed LMBs'
This happens when there is a LMB that the kernel gave up in removing,
and the LMBs previously marked for removal are now being added back.
This happens in the pseries kernel in [1], dlpar_memory_remove_by_ic()
into dlpar_add_lmb(), and after that update_lmb_associativity_index().
In this function, the kernel is configuring the LMB DRC connector again.
Note that this is a valid usage in LOPAR, as stated in section
"ibm,configure-connector RTAS Call":
'A subsequent sequence of calls to ibm,configure-connector with the same
entry from the “ibm,drc-indexes” or “ibm,drc-info” property will restart
the configuration of devices which were not completely configured.'
We can use this kernel behavior in our favor. If a DRC connector
reconfiguration for a LMB that we marked as unplug pending happens, this
indicates that the kernel changed its mind about the unplug and is
reasserting that it will keep using all the LMBs of the DIMM. In this
case, it's safe to assume that the whole DIMM device unplug was
cancelled.
This patch hops into rtas_ibm_configure_connector() and, in the scenario
described above, clear the unplug state for the DIMM device. This will
not solve all the problems we still have with memory unplug, but it will
cover this case where the kernel reconfigures LMBs after a failed
unplug. We are a bit more resilient, without using an unreliable
timeout, and we didn't make the remaining error cases any worse.
[1] arch/powerpc/platforms/pseries/hotplug-memory.c
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-6-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-22 22:45:31 +03:00
|
|
|
}
|
|
|
|
|
2017-05-22 22:35:48 +03:00
|
|
|
/* Callback to be called during DRC release. */
|
|
|
|
void spapr_lmb_release(DeviceState *dev)
|
2016-10-27 05:20:30 +03:00
|
|
|
{
|
2018-06-08 15:48:15 +03:00
|
|
|
HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_ctrl);
|
|
|
|
SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev));
|
2016-10-27 05:20:30 +03:00
|
|
|
|
2017-05-22 22:35:50 +03:00
|
|
|
/* This information will get lost if a migration occurs
|
|
|
|
* during the unplug process. In this case recover it. */
|
|
|
|
if (ds == NULL) {
|
|
|
|
ds = spapr_recover_pending_dimm_state(spapr, PC_DIMM(dev));
|
2017-07-21 07:51:06 +03:00
|
|
|
g_assert(ds);
|
2017-06-06 10:01:21 +03:00
|
|
|
/* The DRC being examined by the caller at least must be counted */
|
|
|
|
g_assert(ds->nr_lmbs);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (--ds->nr_lmbs) {
|
2016-10-27 05:20:30 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that all the LMBs have been removed by the guest, call the
|
2018-06-08 15:48:15 +03:00
|
|
|
* unplug handler chain. This can never fail.
|
2016-10-27 05:20:30 +03:00
|
|
|
*/
|
2018-06-08 15:48:15 +03:00
|
|
|
hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort);
|
qdev: Let the hotplug_handler_unplug() caller delete the device
When unplugging a device, at one point the device will be destroyed
via object_unparent(). This will, one the one hand, unrealize the
removed device hierarchy, and on the other hand, destroy/free the
device hierarchy.
When chaining hotplug handlers, we want to overwrite a bus hotplug
handler by the machine hotplug handler, to be able to perform
some part of the plug/unplug and to forward the calls to the bus hotplug
handler.
For now, the bus hotplug handler would trigger an object_unparent(), not
allowing us to perform some unplug action on a device after we forwarded
the call to the bus hotplug handler. The device would be gone at that
point.
machine_unplug_handler(dev)
/* eventually do unplug stuff */
bus_unplug_handler(dev)
/* dev is gone, we can't do more unplug stuff */
So move the object_unparent() to the original caller of the unplug. For
now, keep the unrealize() at the original places of the
object_unparent(). For implicitly chained hotplug handlers (e.g. pc
code calling acpi hotplug handlers), the object_unparent() has to be
done by the outermost caller. So when calling hotplug_handler_unplug()
from inside an unplug handler, nothing is to be done.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> calls unrealize(dev)
/* we can do more unplug stuff but device already unrealized */
}
object_unparent(dev)
In the long run, every unplug action should be factored out of the
unrealize() function into the unplug handler (especially for PCI). Then
we can get rid of the additonal unrealize() calls and object_unparent()
will properly unrealize the device hierarchy after the device has been
unplugged.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> only unplugs, does not unrealize
/* we can do more unplug stuff */
}
object_unparent(dev) -> will unrealize
The original approach was suggested by Igor Mammedov for the PCI
part, but I extended it to all hotplug handlers. I consider this one
step into the right direction.
To summarize:
- object_unparent() on synchronous unplugs is done by common code
-- "Caller of hotplug_handler_unplug"
- object_unparent() on asynchronous unplugs ("unplug requests") has to
be done manually
-- "Caller of hotplug_handler_unplug"
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190228122849.4296-2-david@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-02-28 15:28:47 +03:00
|
|
|
object_unparent(OBJECT(dev));
|
2018-06-08 15:48:15 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_memory_unplug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev);
|
|
|
|
SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev));
|
2018-06-08 15:48:15 +03:00
|
|
|
|
2021-03-13 10:23:31 +03:00
|
|
|
/* We really shouldn't get this far without anything to unplug */
|
|
|
|
g_assert(ds);
|
|
|
|
|
2018-10-05 12:20:12 +03:00
|
|
|
pc_dimm_unplug(PC_DIMM(dev), MACHINE(hotplug_dev));
|
2020-06-10 08:31:56 +03:00
|
|
|
qdev_unrealize(dev);
|
hw/ppc/spapr.c: abort unplug_request if previous unplug isn't done
LMB removal is completed only when the spapr_lmb_release callback
is called after all DRCs of the dimm are detached. During this
time, it is possible that a unplug request for the same dimm
arrives, trying to detach DRCs that were detached by the guest
in the first unplug_request.
BQL doesn't help in this case - the lock will prevent any concurrent
removal from happening until the end of spapr_memory_unplug_request
only. What happens is that the second unplug_request ends up calling
spapr_drc_detach in a DRC that were detached already, causing an
assert error in spapr_drc_detach (e.g
https://bugs.launchpad.net/qemu/+bug/1718118).
spapr_lmb_release uses a structure called sPAPRDIMMState, stored in the
spapr->pending_dimm_unplugs QTAIL, to track how many LMB DRCs are left
to be detached by the guest. When there are no more DRCs left, this
structure is deleted and the pc-dimm unplug handler is called to
finish the process.
This patch reuses the sPAPRDIMMState to allow unplug_request to know
if there is an ongoing unplug process for a given dimm, aborting the
unplug request in this case, by doing the following changes:
- in spapr_lmb_release callback, move the dimm state removal to the
end, after pc-dimm unplug handler. With this change we can check for
the existence of the dimm state to see if the unplug process is
done.
- use spapr_pending_dimm_unplugs_find in spapr_memory_unplug_request
to check if the dimm state exists. If positive, there is an unplug
operation already in progress for this dimm, meaning that we should
abort it and warn the user about it.
Fixes: https://bugs.launchpad.net/qemu/+bug/1718118
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-10 00:11:36 +03:00
|
|
|
spapr_pending_dimm_unplugs_remove(spapr, ds);
|
2016-10-27 05:20:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_memory_unplug_request(HotplugHandler *hotplug_dev,
|
|
|
|
DeviceState *dev, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev);
|
2016-10-27 05:20:30 +03:00
|
|
|
PCDIMMDevice *dimm = PC_DIMM(dev);
|
2017-08-21 09:30:29 +03:00
|
|
|
uint32_t nr_lmbs;
|
|
|
|
uint64_t size, addr_start, addr;
|
2017-05-24 10:01:48 +03:00
|
|
|
int i;
|
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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2017-08-21 09:30:29 +03:00
|
|
|
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "nvdimm device hot unplug is not supported yet.");
|
|
|
|
return;
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
}
|
|
|
|
|
2018-10-05 12:20:17 +03:00
|
|
|
size = memory_device_get_region_size(MEMORY_DEVICE(dimm), &error_abort);
|
2017-08-21 09:30:29 +03:00
|
|
|
nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
|
2017-06-07 19:36:13 +03:00
|
|
|
addr_start = object_property_get_uint(OBJECT(dimm), PC_DIMM_ADDR_PROP,
|
2020-10-19 11:48:41 +03:00
|
|
|
&error_abort);
|
2016-10-27 05:20:30 +03:00
|
|
|
|
hw/ppc/spapr.c: abort unplug_request if previous unplug isn't done
LMB removal is completed only when the spapr_lmb_release callback
is called after all DRCs of the dimm are detached. During this
time, it is possible that a unplug request for the same dimm
arrives, trying to detach DRCs that were detached by the guest
in the first unplug_request.
BQL doesn't help in this case - the lock will prevent any concurrent
removal from happening until the end of spapr_memory_unplug_request
only. What happens is that the second unplug_request ends up calling
spapr_drc_detach in a DRC that were detached already, causing an
assert error in spapr_drc_detach (e.g
https://bugs.launchpad.net/qemu/+bug/1718118).
spapr_lmb_release uses a structure called sPAPRDIMMState, stored in the
spapr->pending_dimm_unplugs QTAIL, to track how many LMB DRCs are left
to be detached by the guest. When there are no more DRCs left, this
structure is deleted and the pc-dimm unplug handler is called to
finish the process.
This patch reuses the sPAPRDIMMState to allow unplug_request to know
if there is an ongoing unplug process for a given dimm, aborting the
unplug request in this case, by doing the following changes:
- in spapr_lmb_release callback, move the dimm state removal to the
end, after pc-dimm unplug handler. With this change we can check for
the existence of the dimm state to see if the unplug process is
done.
- use spapr_pending_dimm_unplugs_find in spapr_memory_unplug_request
to check if the dimm state exists. If positive, there is an unplug
operation already in progress for this dimm, meaning that we should
abort it and warn the user about it.
Fixes: https://bugs.launchpad.net/qemu/+bug/1718118
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-10 00:11:36 +03:00
|
|
|
/*
|
|
|
|
* An existing pending dimm state for this DIMM means that there is an
|
|
|
|
* unplug operation in progress, waiting for the spapr_lmb_release
|
|
|
|
* callback to complete the job (BQL can't cover that far). In this case,
|
|
|
|
* bail out to avoid detaching DRCs that were already released.
|
|
|
|
*/
|
|
|
|
if (spapr_pending_dimm_unplugs_find(spapr, dimm)) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "Memory unplug already in progress for device %s",
|
hw/ppc/spapr.c: abort unplug_request if previous unplug isn't done
LMB removal is completed only when the spapr_lmb_release callback
is called after all DRCs of the dimm are detached. During this
time, it is possible that a unplug request for the same dimm
arrives, trying to detach DRCs that were detached by the guest
in the first unplug_request.
BQL doesn't help in this case - the lock will prevent any concurrent
removal from happening until the end of spapr_memory_unplug_request
only. What happens is that the second unplug_request ends up calling
spapr_drc_detach in a DRC that were detached already, causing an
assert error in spapr_drc_detach (e.g
https://bugs.launchpad.net/qemu/+bug/1718118).
spapr_lmb_release uses a structure called sPAPRDIMMState, stored in the
spapr->pending_dimm_unplugs QTAIL, to track how many LMB DRCs are left
to be detached by the guest. When there are no more DRCs left, this
structure is deleted and the pc-dimm unplug handler is called to
finish the process.
This patch reuses the sPAPRDIMMState to allow unplug_request to know
if there is an ongoing unplug process for a given dimm, aborting the
unplug request in this case, by doing the following changes:
- in spapr_lmb_release callback, move the dimm state removal to the
end, after pc-dimm unplug handler. With this change we can check for
the existence of the dimm state to see if the unplug process is
done.
- use spapr_pending_dimm_unplugs_find in spapr_memory_unplug_request
to check if the dimm state exists. If positive, there is an unplug
operation already in progress for this dimm, meaning that we should
abort it and warn the user about it.
Fixes: https://bugs.launchpad.net/qemu/+bug/1718118
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-10 00:11:36 +03:00
|
|
|
dev->id);
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
return;
|
hw/ppc/spapr.c: abort unplug_request if previous unplug isn't done
LMB removal is completed only when the spapr_lmb_release callback
is called after all DRCs of the dimm are detached. During this
time, it is possible that a unplug request for the same dimm
arrives, trying to detach DRCs that were detached by the guest
in the first unplug_request.
BQL doesn't help in this case - the lock will prevent any concurrent
removal from happening until the end of spapr_memory_unplug_request
only. What happens is that the second unplug_request ends up calling
spapr_drc_detach in a DRC that were detached already, causing an
assert error in spapr_drc_detach (e.g
https://bugs.launchpad.net/qemu/+bug/1718118).
spapr_lmb_release uses a structure called sPAPRDIMMState, stored in the
spapr->pending_dimm_unplugs QTAIL, to track how many LMB DRCs are left
to be detached by the guest. When there are no more DRCs left, this
structure is deleted and the pc-dimm unplug handler is called to
finish the process.
This patch reuses the sPAPRDIMMState to allow unplug_request to know
if there is an ongoing unplug process for a given dimm, aborting the
unplug request in this case, by doing the following changes:
- in spapr_lmb_release callback, move the dimm state removal to the
end, after pc-dimm unplug handler. With this change we can check for
the existence of the dimm state to see if the unplug process is
done.
- use spapr_pending_dimm_unplugs_find in spapr_memory_unplug_request
to check if the dimm state exists. If positive, there is an unplug
operation already in progress for this dimm, meaning that we should
abort it and warn the user about it.
Fixes: https://bugs.launchpad.net/qemu/+bug/1718118
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-10-10 00:11:36 +03:00
|
|
|
}
|
|
|
|
|
2017-07-21 07:51:06 +03:00
|
|
|
spapr_pending_dimm_unplugs_add(spapr, nr_lmbs, dimm);
|
2017-05-24 10:01:48 +03:00
|
|
|
|
|
|
|
addr = addr_start;
|
|
|
|
for (i = 0; i < nr_lmbs; i++) {
|
2017-06-04 13:26:03 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr / SPAPR_MEMORY_BLOCK_SIZE);
|
2017-05-24 10:01:48 +03:00
|
|
|
g_assert(drc);
|
|
|
|
|
spapr: rename spapr_drc_detach() to spapr_drc_unplug_request()
spapr_drc_detach() is not the best name for what the function does. The
function does not detach the DRC, it makes an uncommited attempt to do
it. It'll mark the DRC as pending unplug, via the 'unplug_request'
flag, and only if the DRC state is drck->empty_state it will detach the
DRC, via spapr_drc_release().
This is a contrast with its pair spapr_drc_attach(), where the function
is indeed creating the DRC QOM object. If you know what
spapr_drc_attach() does, you can be misled into thinking that
spapr_drc_detach() is removing the DRC from QEMU internal state, which
isn't true.
The current role of this function is better described as a request for
detach, since there's no guarantee that we're going to detach the DRC in
the end. Rename the function to spapr_drc_unplug_request to reflect
what is is doing.
The initial idea was to change the name to spapr_drc_detach_request(),
and later on change the unplug_request flag to detach_request. However,
unplug_request is a migratable boolean for a long time now and renaming
it is not worth the trouble. spapr_drc_unplug_request() setting
drc->unplug_request is more natural than spapr_drc_detach_request
setting drc->unplug_request.
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-22 22:45:28 +03:00
|
|
|
spapr_drc_unplug_request(drc);
|
2017-05-24 10:01:48 +03:00
|
|
|
addr += SPAPR_MEMORY_BLOCK_SIZE;
|
|
|
|
}
|
|
|
|
|
2017-06-04 13:26:03 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_LMB,
|
|
|
|
addr_start / SPAPR_MEMORY_BLOCK_SIZE);
|
2017-05-24 10:01:48 +03:00
|
|
|
spapr_hotplug_req_remove_by_count_indexed(SPAPR_DR_CONNECTOR_TYPE_LMB,
|
2017-06-02 06:49:20 +03:00
|
|
|
nr_lmbs, spapr_drc_index(drc));
|
2016-10-27 05:20:30 +03:00
|
|
|
}
|
|
|
|
|
2017-07-13 03:45:35 +03:00
|
|
|
/* Callback to be called during DRC release. */
|
|
|
|
void spapr_core_release(DeviceState *dev)
|
2017-02-02 18:02:34 +03:00
|
|
|
{
|
2018-06-08 15:48:16 +03:00
|
|
|
HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev);
|
|
|
|
|
|
|
|
/* Call the unplug handler chain. This can never fail. */
|
|
|
|
hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort);
|
qdev: Let the hotplug_handler_unplug() caller delete the device
When unplugging a device, at one point the device will be destroyed
via object_unparent(). This will, one the one hand, unrealize the
removed device hierarchy, and on the other hand, destroy/free the
device hierarchy.
When chaining hotplug handlers, we want to overwrite a bus hotplug
handler by the machine hotplug handler, to be able to perform
some part of the plug/unplug and to forward the calls to the bus hotplug
handler.
For now, the bus hotplug handler would trigger an object_unparent(), not
allowing us to perform some unplug action on a device after we forwarded
the call to the bus hotplug handler. The device would be gone at that
point.
machine_unplug_handler(dev)
/* eventually do unplug stuff */
bus_unplug_handler(dev)
/* dev is gone, we can't do more unplug stuff */
So move the object_unparent() to the original caller of the unplug. For
now, keep the unrealize() at the original places of the
object_unparent(). For implicitly chained hotplug handlers (e.g. pc
code calling acpi hotplug handlers), the object_unparent() has to be
done by the outermost caller. So when calling hotplug_handler_unplug()
from inside an unplug handler, nothing is to be done.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> calls unrealize(dev)
/* we can do more unplug stuff but device already unrealized */
}
object_unparent(dev)
In the long run, every unplug action should be factored out of the
unrealize() function into the unplug handler (especially for PCI). Then
we can get rid of the additonal unrealize() calls and object_unparent()
will properly unrealize the device hierarchy after the device has been
unplugged.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> only unplugs, does not unrealize
/* we can do more unplug stuff */
}
object_unparent(dev) -> will unrealize
The original approach was suggested by Igor Mammedov for the PCI
part, but I extended it to all hotplug handlers. I consider this one
step into the right direction.
To summarize:
- object_unparent() on synchronous unplugs is done by common code
-- "Caller of hotplug_handler_unplug"
- object_unparent() on asynchronous unplugs ("unplug requests") has to
be done manually
-- "Caller of hotplug_handler_unplug"
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190228122849.4296-2-david@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-02-28 15:28:47 +03:00
|
|
|
object_unparent(OBJECT(dev));
|
2018-06-08 15:48:16 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
|
|
|
{
|
|
|
|
MachineState *ms = MACHINE(hotplug_dev);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(ms);
|
2017-02-02 18:02:34 +03:00
|
|
|
CPUCore *cc = CPU_CORE(dev);
|
2017-02-10 13:18:49 +03:00
|
|
|
CPUArchId *core_slot = spapr_find_cpu_slot(ms, cc->core_id, NULL);
|
2017-02-02 18:02:34 +03:00
|
|
|
|
2017-06-14 16:29:19 +03:00
|
|
|
if (smc->pre_2_10_has_unused_icps) {
|
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 07:35:37 +03:00
|
|
|
SpaprCpuCore *sc = SPAPR_CPU_CORE(OBJECT(dev));
|
2017-06-14 16:29:19 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < cc->nr_threads; i++) {
|
2017-11-20 12:19:54 +03:00
|
|
|
CPUState *cs = CPU(sc->threads[i]);
|
2017-06-14 16:29:19 +03:00
|
|
|
|
|
|
|
pre_2_10_vmstate_register_dummy_icp(cs->cpu_index);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-18 16:58:31 +03:00
|
|
|
assert(core_slot);
|
2017-02-10 13:18:49 +03:00
|
|
|
core_slot->cpu = NULL;
|
2020-06-10 08:31:56 +03:00
|
|
|
qdev_unrealize(dev);
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
2017-02-02 18:02:35 +03:00
|
|
|
static
|
|
|
|
void spapr_core_unplug_request(HotplugHandler *hotplug_dev, DeviceState *dev,
|
|
|
|
Error **errp)
|
2017-02-02 18:02:34 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
2017-02-10 13:18:49 +03:00
|
|
|
int index;
|
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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2017-02-10 13:18:49 +03:00
|
|
|
CPUCore *cc = CPU_CORE(dev);
|
2017-02-02 18:02:34 +03:00
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
if (!spapr_find_cpu_slot(MACHINE(hotplug_dev), cc->core_id, &index)) {
|
|
|
|
error_setg(errp, "Unable to find CPU core with core-id: %d",
|
|
|
|
cc->core_id);
|
|
|
|
return;
|
|
|
|
}
|
2017-02-02 18:02:34 +03:00
|
|
|
if (index == 0) {
|
|
|
|
error_setg(errp, "Boot CPU core may not be unplugged");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-02-14 22:40:53 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_CPU,
|
|
|
|
spapr_vcpu_id(spapr, cc->core_id));
|
2017-02-02 18:02:34 +03:00
|
|
|
g_assert(drc);
|
|
|
|
|
2019-10-23 22:17:40 +03:00
|
|
|
if (!spapr_drc_unplug_requested(drc)) {
|
spapr: rename spapr_drc_detach() to spapr_drc_unplug_request()
spapr_drc_detach() is not the best name for what the function does. The
function does not detach the DRC, it makes an uncommited attempt to do
it. It'll mark the DRC as pending unplug, via the 'unplug_request'
flag, and only if the DRC state is drck->empty_state it will detach the
DRC, via spapr_drc_release().
This is a contrast with its pair spapr_drc_attach(), where the function
is indeed creating the DRC QOM object. If you know what
spapr_drc_attach() does, you can be misled into thinking that
spapr_drc_detach() is removing the DRC from QEMU internal state, which
isn't true.
The current role of this function is better described as a request for
detach, since there's no guarantee that we're going to detach the DRC in
the end. Rename the function to spapr_drc_unplug_request to reflect
what is is doing.
The initial idea was to change the name to spapr_drc_detach_request(),
and later on change the unplug_request flag to detach_request. However,
unplug_request is a migratable boolean for a long time now and renaming
it is not worth the trouble. spapr_drc_unplug_request() setting
drc->unplug_request is more natural than spapr_drc_detach_request
setting drc->unplug_request.
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-22 22:45:28 +03:00
|
|
|
spapr_drc_unplug_request(drc);
|
2019-10-23 22:17:40 +03:00
|
|
|
}
|
spapr.c: always pulse guest IRQ in spapr_core_unplug_request()
Commit 47c8c915b162 fixed a problem where multiple spapr_drc_detach()
requests were breaking QEMU. The solution was to just spapr_drc_detach()
once, and use spapr_drc_unplug_requested() to filter whether we already
detached it or not. The commit also tied the hotplug request to the
guest in the same condition.
Turns out that there is a reliable way for a CPU hotunplug to fail. If a
guest with one CPU hotplugs a CPU1, then offline CPU0s via 'echo 0 >
/sys/devices/system/cpu/cpu0/online', then attempts to hotunplug CPU1,
the kernel will refuse it because it's the last online CPU of the
system. Given that we're pulsing the IRQ only in the first try, in a
failed attempt, all other CPU1 hotunplug attempts will fail, regardless
of the online state of CPU1 in the kernel, because we're simply not
letting the guest know that we want to hotunplug the device.
Let's move spapr_hotplug_req_remove_by_index() back out of the "if
(!spapr_drc_unplug_requested(drc))" conditional, allowing for multiple
'device_del' requests to the same CPU core to reach the guest, in case
the CPU core didn't fully hotunplugged previously.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210401000437.131140-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-04-01 03:04:37 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* spapr_hotplug_req_remove_by_index is left unguarded, out of the
|
|
|
|
* "!spapr_drc_unplug_requested" check, to allow for multiple IRQ
|
|
|
|
* pulses removing the same CPU. Otherwise, in an failed hotunplug
|
|
|
|
* attempt (e.g. the kernel will refuse to remove the last online
|
|
|
|
* CPU), we will never attempt it again because unplug_requested
|
|
|
|
* will still be 'true' in that case.
|
|
|
|
*/
|
|
|
|
spapr_hotplug_req_remove_by_index(drc);
|
2017-02-02 18:02:34 +03: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 07:35:37 +03:00
|
|
|
int spapr_core_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr,
|
2019-02-19 20:17:48 +03:00
|
|
|
void *fdt, int *fdt_start_offset, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprCpuCore *core = SPAPR_CPU_CORE(drc->dev);
|
2019-02-19 20:17:48 +03:00
|
|
|
CPUState *cs = CPU(core->threads[0]);
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
DeviceClass *dc = DEVICE_GET_CLASS(cs);
|
|
|
|
int id = spapr_get_vcpu_id(cpu);
|
2021-01-21 02:23:04 +03:00
|
|
|
g_autofree char *nodename = NULL;
|
2019-02-19 20:17:48 +03:00
|
|
|
int offset;
|
|
|
|
|
|
|
|
nodename = g_strdup_printf("%s@%x", dc->fw_name, id);
|
|
|
|
offset = fdt_add_subnode(fdt, 0, nodename);
|
|
|
|
|
2020-01-22 08:15:43 +03:00
|
|
|
spapr_dt_cpu(cs, fdt, offset, spapr);
|
2019-02-19 20:17:48 +03:00
|
|
|
|
2021-01-21 02:23:05 +03:00
|
|
|
/*
|
|
|
|
* spapr_dt_cpu() does not fill the 'name' property in the
|
|
|
|
* CPU node. The function is called during boot process, before
|
|
|
|
* and after CAS, and overwriting the 'name' property written
|
|
|
|
* by SLOF is not allowed.
|
|
|
|
*
|
|
|
|
* Write it manually after spapr_dt_cpu(). This makes the hotplug
|
|
|
|
* CPUs more compatible with the coldplugged ones, which have
|
|
|
|
* the 'name' property. Linux Kernel also relies on this
|
|
|
|
* property to identify CPU nodes.
|
|
|
|
*/
|
|
|
|
_FDT((fdt_setprop_string(fdt, offset, "name", nodename)));
|
|
|
|
|
2019-02-19 20:17:48 +03:00
|
|
|
*fdt_start_offset = offset;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-12-01 14:37:27 +03:00
|
|
|
static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
2017-02-02 18:02:34 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
2017-02-02 18:02:34 +03:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(spapr);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
|
|
|
SpaprCpuCore *core = SPAPR_CPU_CORE(OBJECT(dev));
|
2017-02-02 18:02:34 +03:00
|
|
|
CPUCore *cc = CPU_CORE(dev);
|
2019-02-19 20:17:48 +03:00
|
|
|
CPUState *cs;
|
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 07:35:37 +03:00
|
|
|
SpaprDrc *drc;
|
2017-02-10 13:18:49 +03:00
|
|
|
CPUArchId *core_slot;
|
|
|
|
int index;
|
spapr: Treat devices added before inbound migration as coldplugged
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence. However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.
If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.
In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.
In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.
To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management. We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).
This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-09 14:08:10 +03:00
|
|
|
bool hotplugged = spapr_drc_hotplugged(dev);
|
2019-08-28 20:20:53 +03:00
|
|
|
int i;
|
2017-02-02 18:02:34 +03:00
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
core_slot = spapr_find_cpu_slot(MACHINE(hotplug_dev), cc->core_id, &index);
|
2020-12-01 14:37:27 +03:00
|
|
|
g_assert(core_slot); /* Already checked in spapr_core_pre_plug() */
|
|
|
|
|
2018-02-14 22:40:53 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_CPU,
|
|
|
|
spapr_vcpu_id(spapr, cc->core_id));
|
2017-02-02 18:02:34 +03:00
|
|
|
|
2017-02-10 13:20:57 +03:00
|
|
|
g_assert(drc || !mc->has_hotpluggable_cpus);
|
2017-02-02 18:02:34 +03:00
|
|
|
|
|
|
|
if (drc) {
|
2020-12-01 14:37:27 +03:00
|
|
|
/*
|
|
|
|
* spapr_core_pre_plug() already buys us this is a brand new
|
|
|
|
* core being plugged into a free slot. Nothing should already
|
|
|
|
* be attached to the corresponding DRC.
|
|
|
|
*/
|
2020-12-01 14:37:28 +03:00
|
|
|
spapr_drc_attach(drc, dev);
|
2017-02-02 18:02:34 +03:00
|
|
|
|
spapr: Treat devices added before inbound migration as coldplugged
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence. However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.
If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.
In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.
In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.
To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management. We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).
This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-09 14:08:10 +03:00
|
|
|
if (hotplugged) {
|
|
|
|
/*
|
|
|
|
* Send hotplug notification interrupt to the guest only
|
|
|
|
* in case of hotplugged CPUs.
|
|
|
|
*/
|
|
|
|
spapr_hotplug_req_add_by_index(drc);
|
|
|
|
} else {
|
|
|
|
spapr_drc_reset(drc);
|
|
|
|
}
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
spapr: Treat devices added before inbound migration as coldplugged
When migrating a guest which has already had devices hotplugged,
libvirt typically starts the destination qemu with -incoming defer,
adds those hotplugged devices with qmp, then initiates the incoming
migration.
This causes problems for the management of spapr DRC state. Because
the device is treated as hotplugged, it goes into a DRC state for a
device immediately after it's plugged, but before the guest has
acknowledged its presence. However, chances are the guest on the
source machine *has* acknowledged the device's presence and configured
it.
If the source has fully configured the device, then DRC state won't be
sent in the migration stream: for maximum migration compatibility with
earlier versions we don't migrate DRCs in coldplug-equivalent state.
That means that the DRC effectively changes state over the migrate,
causing problems later on.
In addition, logging hotplug events for these devices isn't what we
want because a) those events should already have been issued on the
source host and b) the event queue should get wiped out by the
incoming state anyway.
In short, what we really want is to treat devices added before an
incoming migration as if they were coldplugged.
To do this, we first add a spapr_drc_hotplugged() helper which
determines if the device is hotplugged in the sense relevant for DRC
state management. We only send hotplug events when this is true.
Second, when we add a device which isn't hotplugged in this sense, we
force a reset of the DRC state - this ensures the DRC is in a
coldplug-equivalent state (there isn't usually a system reset between
these device adds and the incoming migration).
This is based on an earlier patch by Laurent Vivier, cleaned up and
extended.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Tested-by: Daniel Barboza <danielhb@linux.vnet.ibm.com>
2017-06-09 14:08:10 +03:00
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
core_slot->cpu = OBJECT(dev);
|
2017-06-14 16:29:19 +03:00
|
|
|
|
2019-08-28 20:20:53 +03:00
|
|
|
/*
|
|
|
|
* Set compatibility mode to match the boot CPU, which was either set
|
2020-12-01 14:37:26 +03:00
|
|
|
* by the machine reset code or by CAS. This really shouldn't fail at
|
|
|
|
* this point.
|
2019-08-28 20:20:53 +03:00
|
|
|
*/
|
|
|
|
if (hotplugged) {
|
|
|
|
for (i = 0; i < cc->nr_threads; i++) {
|
2020-12-01 14:37:26 +03:00
|
|
|
ppc_set_compat(core->threads[i], POWERPC_CPU(first_cpu)->compat_pvr,
|
|
|
|
&error_abort);
|
2019-08-28 20:20:53 +03:00
|
|
|
}
|
|
|
|
}
|
2020-12-01 14:37:25 +03:00
|
|
|
|
|
|
|
if (smc->pre_2_10_has_unused_icps) {
|
|
|
|
for (i = 0; i < cc->nr_threads; i++) {
|
|
|
|
cs = CPU(core->threads[i]);
|
|
|
|
pre_2_10_vmstate_unregister_dummy_icp(cs->cpu_index);
|
|
|
|
}
|
|
|
|
}
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_core_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
|
|
|
|
Error **errp)
|
|
|
|
{
|
|
|
|
MachineState *machine = MACHINE(OBJECT(hotplug_dev));
|
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(hotplug_dev);
|
|
|
|
CPUCore *cc = CPU_CORE(dev);
|
2017-10-09 22:51:05 +03:00
|
|
|
const char *base_core_type = spapr_get_cpu_core_type(machine->cpu_type);
|
2017-02-02 18:02:34 +03:00
|
|
|
const char *type = object_get_typename(OBJECT(dev));
|
2017-02-10 13:18:49 +03:00
|
|
|
CPUArchId *core_slot;
|
|
|
|
int index;
|
2019-05-18 23:54:22 +03:00
|
|
|
unsigned int smp_threads = machine->smp.threads;
|
2017-02-02 18:02:34 +03:00
|
|
|
|
2017-02-10 13:20:57 +03:00
|
|
|
if (dev->hotplugged && !mc->has_hotpluggable_cpus) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "CPU hotplug not supported for this machine");
|
|
|
|
return;
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (strcmp(base_core_type, type)) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "CPU core type should be %s", base_core_type);
|
|
|
|
return;
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (cc->core_id % smp_threads) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "invalid core id %d", cc->core_id);
|
|
|
|
return;
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
2017-05-23 09:33:06 +03:00
|
|
|
/*
|
|
|
|
* In general we should have homogeneous threads-per-core, but old
|
|
|
|
* (pre hotplug support) machine types allow the last core to have
|
|
|
|
* reduced threads as a compatibility hack for when we allowed
|
|
|
|
* total vcpus not a multiple of threads-per-core.
|
|
|
|
*/
|
|
|
|
if (mc->has_hotpluggable_cpus && (cc->nr_threads != smp_threads)) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "invalid nr-threads %d, must be %d", cc->nr_threads,
|
|
|
|
smp_threads);
|
|
|
|
return;
|
2017-04-02 09:14:30 +03:00
|
|
|
}
|
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
core_slot = spapr_find_cpu_slot(MACHINE(hotplug_dev), cc->core_id, &index);
|
|
|
|
if (!core_slot) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "core id %d out of range", cc->core_id);
|
|
|
|
return;
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
if (core_slot->cpu) {
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
error_setg(errp, "core %d already populated", cc->core_id);
|
|
|
|
return;
|
2017-02-02 18:02:34 +03:00
|
|
|
}
|
|
|
|
|
error: Avoid unnecessary error_propagate() after error_setg()
Replace
error_setg(&err, ...);
error_propagate(errp, err);
by
error_setg(errp, ...);
Related pattern:
if (...) {
error_setg(&err, ...);
goto out;
}
...
out:
error_propagate(errp, err);
return;
When all paths to label out are that way, replace by
if (...) {
error_setg(errp, ...);
return;
}
and delete the label along with the error_propagate().
When we have at most one other path that actually needs to propagate,
and maybe one at the end that where propagation is unnecessary, e.g.
foo(..., &err);
if (err) {
goto out;
}
...
bar(..., &err);
out:
error_propagate(errp, err);
return;
move the error_propagate() to where it's needed, like
if (...) {
foo(..., &err);
error_propagate(errp, err);
return;
}
...
bar(..., errp);
return;
and transform the error_setg() as above.
In some places, the transformation results in obviously unnecessary
error_propagate(). The next few commits will eliminate them.
Bonus: the elimination of gotos will make later patches in this series
easier to review.
Candidates for conversion tracked down with this Coccinelle script:
@@
identifier err, errp;
expression list args;
@@
- error_setg(&err, args);
+ error_setg(errp, args);
... when != err
error_propagate(errp, err);
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200707160613.848843-34-armbru@redhat.com>
2020-07-07 19:06:01 +03:00
|
|
|
numa_cpu_pre_plug(core_slot, dev, errp);
|
2017-02-02 18:02:34 +03: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 07:35:37 +03:00
|
|
|
int spapr_phb_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr,
|
2019-02-19 20:18:49 +03:00
|
|
|
void *fdt, int *fdt_start_offset, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(drc->dev);
|
2019-02-19 20:18:49 +03:00
|
|
|
int intc_phandle;
|
|
|
|
|
|
|
|
intc_phandle = spapr_irq_get_phandle(spapr, spapr->fdt_blob, errp);
|
|
|
|
if (intc_phandle <= 0) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-09-27 06:44:58 +03:00
|
|
|
if (spapr_dt_phb(spapr, sphb, intc_phandle, fdt, fdt_start_offset)) {
|
2019-02-19 20:18:49 +03:00
|
|
|
error_setg(errp, "unable to create FDT node for PHB %d", sphb->index);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* generally SLOF creates these, for hotplug it's up to QEMU */
|
|
|
|
_FDT(fdt_setprop_string(fdt, *fdt_start_offset, "name", "pci"));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:05 +03:00
|
|
|
static bool spapr_phb_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
|
2019-02-19 20:18:49 +03:00
|
|
|
Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
|
|
|
SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev);
|
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
2019-02-19 20:18:49 +03:00
|
|
|
const unsigned windows_supported = spapr_phb_windows_supported(sphb);
|
2020-11-21 02:42:06 +03:00
|
|
|
SpaprDrc *drc;
|
2019-02-19 20:18:49 +03:00
|
|
|
|
|
|
|
if (dev->hotplugged && !smc->dr_phb_enabled) {
|
|
|
|
error_setg(errp, "PHB hotplug not supported for this machine");
|
2020-11-21 02:42:05 +03:00
|
|
|
return false;
|
2019-02-19 20:18:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (sphb->index == (uint32_t)-1) {
|
|
|
|
error_setg(errp, "\"index\" for PAPR PHB is mandatory");
|
2020-11-21 02:42:05 +03:00
|
|
|
return false;
|
2019-02-19 20:18:49 +03:00
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:06 +03:00
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_PHB, sphb->index);
|
|
|
|
if (drc && drc->dev) {
|
|
|
|
error_setg(errp, "PHB %d already attached", sphb->index);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-02-19 20:18:49 +03:00
|
|
|
/*
|
|
|
|
* This will check that sphb->index doesn't exceed the maximum number of
|
|
|
|
* PHBs for the current machine type.
|
|
|
|
*/
|
2020-11-21 02:42:05 +03:00
|
|
|
return
|
|
|
|
smc->phb_placement(spapr, sphb->index,
|
|
|
|
&sphb->buid, &sphb->io_win_addr,
|
|
|
|
&sphb->mem_win_addr, &sphb->mem64_win_addr,
|
|
|
|
windows_supported, sphb->dma_liobn,
|
|
|
|
errp);
|
2019-02-19 20:18:49 +03:00
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:06 +03:00
|
|
|
static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
2019-02-19 20:18:49 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
|
|
|
|
SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev);
|
|
|
|
SpaprDrc *drc;
|
2019-02-19 20:18:49 +03:00
|
|
|
bool hotplugged = spapr_drc_hotplugged(dev);
|
|
|
|
|
|
|
|
if (!smc->dr_phb_enabled) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_PHB, sphb->index);
|
|
|
|
/* hotplug hooks should check it's enabled before getting this far */
|
|
|
|
assert(drc);
|
|
|
|
|
2020-11-21 02:42:06 +03:00
|
|
|
/* spapr_phb_pre_plug() already checked the DRC is attachable */
|
2020-12-01 14:37:28 +03:00
|
|
|
spapr_drc_attach(drc, dev);
|
2019-02-19 20:18:49 +03:00
|
|
|
|
|
|
|
if (hotplugged) {
|
|
|
|
spapr_hotplug_req_add_by_index(drc);
|
|
|
|
} else {
|
|
|
|
spapr_drc_reset(drc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void spapr_phb_release(DeviceState *dev)
|
|
|
|
{
|
|
|
|
HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev);
|
|
|
|
|
|
|
|
hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort);
|
qdev: Let the hotplug_handler_unplug() caller delete the device
When unplugging a device, at one point the device will be destroyed
via object_unparent(). This will, one the one hand, unrealize the
removed device hierarchy, and on the other hand, destroy/free the
device hierarchy.
When chaining hotplug handlers, we want to overwrite a bus hotplug
handler by the machine hotplug handler, to be able to perform
some part of the plug/unplug and to forward the calls to the bus hotplug
handler.
For now, the bus hotplug handler would trigger an object_unparent(), not
allowing us to perform some unplug action on a device after we forwarded
the call to the bus hotplug handler. The device would be gone at that
point.
machine_unplug_handler(dev)
/* eventually do unplug stuff */
bus_unplug_handler(dev)
/* dev is gone, we can't do more unplug stuff */
So move the object_unparent() to the original caller of the unplug. For
now, keep the unrealize() at the original places of the
object_unparent(). For implicitly chained hotplug handlers (e.g. pc
code calling acpi hotplug handlers), the object_unparent() has to be
done by the outermost caller. So when calling hotplug_handler_unplug()
from inside an unplug handler, nothing is to be done.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> calls unrealize(dev)
/* we can do more unplug stuff but device already unrealized */
}
object_unparent(dev)
In the long run, every unplug action should be factored out of the
unrealize() function into the unplug handler (especially for PCI). Then
we can get rid of the additonal unrealize() calls and object_unparent()
will properly unrealize the device hierarchy after the device has been
unplugged.
hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
machine_unplug_handler(dev) {
/* eventually do unplug stuff */
bus_unplug_handler(dev) -> only unplugs, does not unrealize
/* we can do more unplug stuff */
}
object_unparent(dev) -> will unrealize
The original approach was suggested by Igor Mammedov for the PCI
part, but I extended it to all hotplug handlers. I consider this one
step into the right direction.
To summarize:
- object_unparent() on synchronous unplugs is done by common code
-- "Caller of hotplug_handler_unplug"
- object_unparent() on asynchronous unplugs ("unplug requests") has to
be done manually
-- "Caller of hotplug_handler_unplug"
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190228122849.4296-2-david@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-02-28 15:28:47 +03:00
|
|
|
object_unparent(OBJECT(dev));
|
2019-02-19 20:18:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_phb_unplug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
|
|
|
{
|
2020-06-10 08:31:56 +03:00
|
|
|
qdev_unrealize(dev);
|
2019-02-19 20:18:49 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_phb_unplug_request(HotplugHandler *hotplug_dev,
|
|
|
|
DeviceState *dev, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev);
|
|
|
|
SpaprDrc *drc;
|
2019-02-19 20:18:49 +03:00
|
|
|
|
|
|
|
drc = spapr_drc_by_id(TYPE_SPAPR_DRC_PHB, sphb->index);
|
|
|
|
assert(drc);
|
|
|
|
|
|
|
|
if (!spapr_drc_unplug_requested(drc)) {
|
spapr: rename spapr_drc_detach() to spapr_drc_unplug_request()
spapr_drc_detach() is not the best name for what the function does. The
function does not detach the DRC, it makes an uncommited attempt to do
it. It'll mark the DRC as pending unplug, via the 'unplug_request'
flag, and only if the DRC state is drck->empty_state it will detach the
DRC, via spapr_drc_release().
This is a contrast with its pair spapr_drc_attach(), where the function
is indeed creating the DRC QOM object. If you know what
spapr_drc_attach() does, you can be misled into thinking that
spapr_drc_detach() is removing the DRC from QEMU internal state, which
isn't true.
The current role of this function is better described as a request for
detach, since there's no guarantee that we're going to detach the DRC in
the end. Rename the function to spapr_drc_unplug_request to reflect
what is is doing.
The initial idea was to change the name to spapr_drc_detach_request(),
and later on change the unplug_request flag to detach_request. However,
unplug_request is a migratable boolean for a long time now and renaming
it is not worth the trouble. spapr_drc_unplug_request() setting
drc->unplug_request is more natural than spapr_drc_detach_request
setting drc->unplug_request.
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210222194531.62717-3-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-02-22 22:45:28 +03:00
|
|
|
spapr_drc_unplug_request(drc);
|
2019-02-19 20:18:49 +03:00
|
|
|
spapr_hotplug_req_remove_by_index(drc);
|
2021-02-26 19:32:59 +03:00
|
|
|
} else {
|
|
|
|
error_setg(errp,
|
|
|
|
"PCI Host Bridge unplug already in progress for device %s",
|
|
|
|
dev->id);
|
2019-02-19 20:18:49 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:07 +03:00
|
|
|
static
|
|
|
|
bool spapr_tpm_proxy_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
|
|
|
|
Error **errp)
|
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 23:58:42 +03:00
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
|
|
|
|
|
|
|
if (spapr->tpm_proxy != NULL) {
|
|
|
|
error_setg(errp, "Only one TPM proxy can be specified for this machine");
|
2020-11-21 02:42:07 +03:00
|
|
|
return false;
|
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 23:58:42 +03:00
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:07 +03:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_tpm_proxy_plug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
|
|
|
SpaprTpmProxy *tpm_proxy = SPAPR_TPM_PROXY(dev);
|
|
|
|
|
|
|
|
/* Already checked in spapr_tpm_proxy_pre_plug() */
|
|
|
|
g_assert(spapr->tpm_proxy == NULL);
|
|
|
|
|
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 23:58:42 +03:00
|
|
|
spapr->tpm_proxy = tpm_proxy;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_tpm_proxy_unplug(HotplugHandler *hotplug_dev, DeviceState *dev)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
|
|
|
|
2020-06-10 08:31:56 +03:00
|
|
|
qdev_unrealize(dev);
|
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 23:58:42 +03:00
|
|
|
object_unparent(OBJECT(dev));
|
|
|
|
spapr->tpm_proxy = NULL;
|
|
|
|
}
|
|
|
|
|
2015-09-01 04:22:35 +03:00
|
|
|
static void spapr_machine_device_plug(HotplugHandler *hotplug_dev,
|
|
|
|
DeviceState *dev, Error **errp)
|
|
|
|
{
|
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
|
2020-11-21 02:42:01 +03:00
|
|
|
spapr_memory_plug(hotplug_dev, dev);
|
2016-06-10 03:59:04 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
|
2020-12-01 14:37:27 +03:00
|
|
|
spapr_core_plug(hotplug_dev, dev);
|
2019-02-19 20:18:49 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_PCI_HOST_BRIDGE)) {
|
2020-11-21 02:42:06 +03:00
|
|
|
spapr_phb_plug(hotplug_dev, dev);
|
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 23:58:42 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_TPM_PROXY)) {
|
2020-11-21 02:42:07 +03:00
|
|
|
spapr_tpm_proxy_plug(hotplug_dev, dev);
|
2015-09-01 04:22:35 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-08 15:48:14 +03:00
|
|
|
static void spapr_machine_device_unplug(HotplugHandler *hotplug_dev,
|
|
|
|
DeviceState *dev, Error **errp)
|
|
|
|
{
|
2018-06-08 15:48:15 +03:00
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
|
|
|
|
spapr_memory_unplug(hotplug_dev, dev);
|
2018-06-08 15:48:16 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
|
|
|
|
spapr_core_unplug(hotplug_dev, dev);
|
2019-02-19 20:18:49 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_PCI_HOST_BRIDGE)) {
|
|
|
|
spapr_phb_unplug(hotplug_dev, dev);
|
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 23:58:42 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_TPM_PROXY)) {
|
|
|
|
spapr_tpm_proxy_unplug(hotplug_dev, dev);
|
2018-06-08 15:48:15 +03:00
|
|
|
}
|
2018-06-08 15:48:14 +03:00
|
|
|
}
|
|
|
|
|
2021-01-08 20:31:27 +03:00
|
|
|
bool spapr_memory_hot_unplug_supported(SpaprMachineState *spapr)
|
|
|
|
{
|
|
|
|
return spapr_ovec_test(spapr->ov5_cas, OV5_HP_EVT) ||
|
|
|
|
/*
|
|
|
|
* CAS will process all pending unplug requests.
|
|
|
|
*
|
|
|
|
* HACK: a guest could theoretically have cleared all bits in OV5,
|
|
|
|
* but none of the guests we care for do.
|
|
|
|
*/
|
|
|
|
spapr_ovec_empty(spapr->ov5_cas);
|
|
|
|
}
|
|
|
|
|
2016-10-27 05:20:30 +03:00
|
|
|
static void spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev,
|
|
|
|
DeviceState *dev, Error **errp)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *sms = SPAPR_MACHINE(OBJECT(hotplug_dev));
|
2017-09-06 21:43:05 +03:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(sms);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2016-10-27 05:20:30 +03:00
|
|
|
|
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
|
2021-01-08 20:31:27 +03:00
|
|
|
if (spapr_memory_hot_unplug_supported(sms)) {
|
2016-10-27 05:20:30 +03:00
|
|
|
spapr_memory_unplug_request(hotplug_dev, dev, errp);
|
|
|
|
} else {
|
|
|
|
error_setg(errp, "Memory hot unplug not supported for this guest");
|
|
|
|
}
|
2016-06-10 03:59:05 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
|
2017-02-10 13:20:57 +03:00
|
|
|
if (!mc->has_hotpluggable_cpus) {
|
2016-06-10 03:59:05 +03:00
|
|
|
error_setg(errp, "CPU hot unplug not supported on this machine");
|
|
|
|
return;
|
|
|
|
}
|
2017-02-02 18:02:35 +03:00
|
|
|
spapr_core_unplug_request(hotplug_dev, dev, errp);
|
2019-02-19 20:18:49 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_PCI_HOST_BRIDGE)) {
|
|
|
|
if (!smc->dr_phb_enabled) {
|
|
|
|
error_setg(errp, "PHB hot unplug not supported on this machine");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
spapr_phb_unplug_request(hotplug_dev, dev, errp);
|
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 23:58:42 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_TPM_PROXY)) {
|
|
|
|
spapr_tpm_proxy_unplug(hotplug_dev, dev);
|
2015-09-01 04:22:35 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-10 03:59:03 +03:00
|
|
|
static void spapr_machine_device_pre_plug(HotplugHandler *hotplug_dev,
|
|
|
|
DeviceState *dev, Error **errp)
|
|
|
|
{
|
2017-05-23 14:18:09 +03:00
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
|
|
|
|
spapr_memory_pre_plug(hotplug_dev, dev, errp);
|
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
|
2016-06-10 03:59:03 +03:00
|
|
|
spapr_core_pre_plug(hotplug_dev, dev, errp);
|
2019-02-19 20:18:49 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_PCI_HOST_BRIDGE)) {
|
|
|
|
spapr_phb_pre_plug(hotplug_dev, dev, errp);
|
2020-11-21 02:42:07 +03:00
|
|
|
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_TPM_PROXY)) {
|
|
|
|
spapr_tpm_proxy_pre_plug(hotplug_dev, dev, errp);
|
2016-06-10 03:59:03 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-12 10:57:20 +03:00
|
|
|
static HotplugHandler *spapr_get_hotplug_handler(MachineState *machine,
|
|
|
|
DeviceState *dev)
|
2015-09-01 04:22:35 +03:00
|
|
|
{
|
2016-06-10 03:59:03 +03:00
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) ||
|
2019-02-19 20:18:49 +03:00
|
|
|
object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE) ||
|
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 23:58:42 +03:00
|
|
|
object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_PCI_HOST_BRIDGE) ||
|
|
|
|
object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_TPM_PROXY)) {
|
2015-09-01 04:22:35 +03:00
|
|
|
return HOTPLUG_HANDLER(machine);
|
|
|
|
}
|
2019-02-15 08:50:40 +03:00
|
|
|
if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
|
|
|
|
PCIDevice *pcidev = PCI_DEVICE(dev);
|
|
|
|
PCIBus *root = pci_device_root_bus(pcidev);
|
|
|
|
SpaprPhbState *phb =
|
|
|
|
(SpaprPhbState *)object_dynamic_cast(OBJECT(BUS(root)->parent),
|
|
|
|
TYPE_SPAPR_PCI_HOST_BRIDGE);
|
|
|
|
|
|
|
|
if (phb) {
|
|
|
|
return HOTPLUG_HANDLER(phb);
|
|
|
|
}
|
|
|
|
}
|
2015-09-01 04:22:35 +03:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-05-10 14:29:45 +03:00
|
|
|
static CpuInstanceProperties
|
|
|
|
spapr_cpu_index_to_props(MachineState *machine, unsigned cpu_index)
|
2015-09-08 04:21:52 +03:00
|
|
|
{
|
2017-05-10 14:29:45 +03:00
|
|
|
CPUArchId *core_slot;
|
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(machine);
|
|
|
|
|
2023-07-14 14:18:16 +03:00
|
|
|
/* make sure possible_cpu are initialized */
|
2017-05-10 14:29:45 +03:00
|
|
|
mc->possible_cpu_arch_ids(machine);
|
|
|
|
/* get CPU core slot containing thread that matches cpu_index */
|
|
|
|
core_slot = spapr_find_cpu_slot(machine, cpu_index, NULL);
|
|
|
|
assert(core_slot);
|
|
|
|
return core_slot->props;
|
2015-09-08 04:21:52 +03:00
|
|
|
}
|
|
|
|
|
2017-06-01 13:53:28 +03:00
|
|
|
static int64_t spapr_get_default_cpu_node_id(const MachineState *ms, int idx)
|
|
|
|
{
|
2019-08-09 09:57:22 +03:00
|
|
|
return idx / ms->smp.cores % ms->numa_state->num_nodes;
|
2017-06-01 13:53:28 +03:00
|
|
|
}
|
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
static const CPUArchIdList *spapr_possible_cpu_arch_ids(MachineState *machine)
|
|
|
|
{
|
|
|
|
int i;
|
2019-05-18 23:54:22 +03:00
|
|
|
unsigned int smp_threads = machine->smp.threads;
|
|
|
|
unsigned int smp_cpus = machine->smp.cpus;
|
2018-01-10 18:22:50 +03:00
|
|
|
const char *core_type;
|
2019-05-18 23:54:22 +03:00
|
|
|
int spapr_max_cores = machine->smp.max_cpus / smp_threads;
|
2017-02-10 13:18:49 +03:00
|
|
|
MachineClass *mc = MACHINE_GET_CLASS(machine);
|
|
|
|
|
2017-02-10 13:20:57 +03:00
|
|
|
if (!mc->has_hotpluggable_cpus) {
|
2017-02-10 13:18:49 +03:00
|
|
|
spapr_max_cores = QEMU_ALIGN_UP(smp_cpus, smp_threads) / smp_threads;
|
|
|
|
}
|
|
|
|
if (machine->possible_cpus) {
|
|
|
|
assert(machine->possible_cpus->len == spapr_max_cores);
|
|
|
|
return machine->possible_cpus;
|
|
|
|
}
|
|
|
|
|
2018-01-10 18:22:50 +03:00
|
|
|
core_type = spapr_get_cpu_core_type(machine->cpu_type);
|
|
|
|
if (!core_type) {
|
|
|
|
error_report("Unable to find sPAPR CPU Core definition");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2017-02-10 13:18:49 +03:00
|
|
|
machine->possible_cpus = g_malloc0(sizeof(CPUArchIdList) +
|
|
|
|
sizeof(CPUArchId) * spapr_max_cores);
|
|
|
|
machine->possible_cpus->len = spapr_max_cores;
|
|
|
|
for (i = 0; i < machine->possible_cpus->len; i++) {
|
|
|
|
int core_id = i * smp_threads;
|
|
|
|
|
2018-01-10 18:22:50 +03:00
|
|
|
machine->possible_cpus->cpus[i].type = core_type;
|
2017-02-09 14:08:38 +03:00
|
|
|
machine->possible_cpus->cpus[i].vcpus_count = smp_threads;
|
2017-02-10 13:18:49 +03:00
|
|
|
machine->possible_cpus->cpus[i].arch_id = core_id;
|
|
|
|
machine->possible_cpus->cpus[i].props.has_core_id = true;
|
|
|
|
machine->possible_cpus->cpus[i].props.core_id = core_id;
|
|
|
|
}
|
|
|
|
return machine->possible_cpus;
|
|
|
|
}
|
|
|
|
|
2020-11-21 02:42:05 +03:00
|
|
|
static bool spapr_phb_placement(SpaprMachineState *spapr, uint32_t index,
|
spapr_pci: Add a 64-bit MMIO window
On real hardware, and under pHyp, the PCI host bridges on Power machines
typically advertise two outbound MMIO windows from the guest's physical
memory space to PCI memory space:
- A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
- A 64-bit window which maps onto a large region somewhere high in PCI
address space (traditionally this used an identity mapping from guest
physical address to PCI address, but that's not always the case)
The qemu implementation in spapr-pci-host-bridge, however, only supports a
single outbound MMIO window, however. At least some Linux versions expect
the two windows however, so we arranged this window to map onto the PCI
memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
windows, the "32-bit" window from 2G..4G and the "64-bit" window from
4G..~64G.
This approach means, however, that the 64G window is not naturally aligned.
In turn this limits the size of the largest BAR we can map (which does have
to be naturally aligned) to roughly half of the total window. With some
large nVidia GPGPU cards which have huge memory BARs, this is starting to
be a problem.
This patch adds true support for separate 32-bit and 64-bit outbound MMIO
windows to the spapr-pci-host-bridge implementation, each of which can
be independently configured. The 32-bit window always maps to 2G.. in PCI
space, but the PCI address of the 64-bit window can be configured (it
defaults to the same as the guest physical address).
So as not to break possible existing configurations, as long as a 64-bit
window is not specified, a large single window can be specified. This
will appear the same way to the guest as the old approach, although it's
now implemented by two contiguous memory regions rather than a single one.
For now, this only adds the possibility of 64-bit windows. The default
configuration still uses the legacy mode.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2016-10-11 06:23:33 +03:00
|
|
|
uint64_t *buid, hwaddr *pio,
|
|
|
|
hwaddr *mmio32, hwaddr *mmio64,
|
2023-09-18 12:17:17 +03:00
|
|
|
unsigned n_dma, uint32_t *liobns, Error **errp)
|
spapr_pci: Delegate placement of PCI host bridges to machine type
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows. This gives the most control, but is very awkward with 6
mandatory parameters. Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.
The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO). Obviously, for migration we can only change the
locations on a new machine type, however.
This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.
So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass. It's still a bit ugly, but it's about the best we
can do.
For now, this just changes where the calculation is done. It doesn't
change the actual location of the host bridges, or any other behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2016-10-13 02:26:09 +03:00
|
|
|
{
|
2016-10-16 04:04:15 +03:00
|
|
|
/*
|
|
|
|
* New-style PHB window placement.
|
|
|
|
*
|
|
|
|
* Goals: Gives large (1TiB), naturally aligned 64-bit MMIO window
|
|
|
|
* for each PHB, in addition to 2GiB 32-bit MMIO and 64kiB PIO
|
|
|
|
* windows.
|
|
|
|
*
|
|
|
|
* Some guest kernels can't work with MMIO windows above 1<<46
|
|
|
|
* (64TiB), so we place up to 31 PHBs in the area 32TiB..64TiB
|
|
|
|
*
|
|
|
|
* 32TiB..(33TiB+1984kiB) contains the 64kiB PIO windows for each
|
|
|
|
* PHB stacked together. (32TiB+2GiB)..(32TiB+64GiB) contains the
|
|
|
|
* 2GiB 32-bit MMIO windows for each PHB. Then 33..64TiB has the
|
|
|
|
* 1TiB 64-bit MMIO windows for each PHB.
|
|
|
|
*/
|
spapr_pci: Delegate placement of PCI host bridges to machine type
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows. This gives the most control, but is very awkward with 6
mandatory parameters. Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.
The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO). Obviously, for migration we can only change the
locations on a new machine type, however.
This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.
So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass. It's still a bit ugly, but it's about the best we
can do.
For now, this just changes where the calculation is done. It doesn't
change the actual location of the host bridges, or any other behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2016-10-13 02:26:09 +03:00
|
|
|
const uint64_t base_buid = 0x800000020000000ULL;
|
|
|
|
int i;
|
|
|
|
|
2016-10-16 04:04:15 +03:00
|
|
|
/* Sanity check natural alignments */
|
|
|
|
QEMU_BUILD_BUG_ON((SPAPR_PCI_BASE % SPAPR_PCI_MEM64_WIN_SIZE) != 0);
|
|
|
|
QEMU_BUILD_BUG_ON((SPAPR_PCI_LIMIT % SPAPR_PCI_MEM64_WIN_SIZE) != 0);
|
|
|
|
QEMU_BUILD_BUG_ON((SPAPR_PCI_MEM64_WIN_SIZE % SPAPR_PCI_MEM32_WIN_SIZE) != 0);
|
|
|
|
QEMU_BUILD_BUG_ON((SPAPR_PCI_MEM32_WIN_SIZE % SPAPR_PCI_IO_WIN_SIZE) != 0);
|
|
|
|
/* Sanity check bounds */
|
2017-01-27 19:27:16 +03:00
|
|
|
QEMU_BUILD_BUG_ON((SPAPR_MAX_PHBS * SPAPR_PCI_IO_WIN_SIZE) >
|
|
|
|
SPAPR_PCI_MEM32_WIN_SIZE);
|
|
|
|
QEMU_BUILD_BUG_ON((SPAPR_MAX_PHBS * SPAPR_PCI_MEM32_WIN_SIZE) >
|
|
|
|
SPAPR_PCI_MEM64_WIN_SIZE);
|
|
|
|
|
|
|
|
if (index >= SPAPR_MAX_PHBS) {
|
|
|
|
error_setg(errp, "\"index\" for PAPR PHB is too large (max %llu)",
|
|
|
|
SPAPR_MAX_PHBS - 1);
|
2020-11-21 02:42:05 +03:00
|
|
|
return false;
|
spapr_pci: Delegate placement of PCI host bridges to machine type
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows. This gives the most control, but is very awkward with 6
mandatory parameters. Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.
The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO). Obviously, for migration we can only change the
locations on a new machine type, however.
This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.
So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass. It's still a bit ugly, but it's about the best we
can do.
For now, this just changes where the calculation is done. It doesn't
change the actual location of the host bridges, or any other behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2016-10-13 02:26:09 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
*buid = base_buid + index;
|
|
|
|
for (i = 0; i < n_dma; ++i) {
|
|
|
|
liobns[i] = SPAPR_PCI_LIOBN(index, i);
|
|
|
|
}
|
|
|
|
|
2016-10-16 04:04:15 +03:00
|
|
|
*pio = SPAPR_PCI_BASE + index * SPAPR_PCI_IO_WIN_SIZE;
|
|
|
|
*mmio32 = SPAPR_PCI_BASE + (index + 1) * SPAPR_PCI_MEM32_WIN_SIZE;
|
|
|
|
*mmio64 = SPAPR_PCI_BASE + (index + 1) * SPAPR_PCI_MEM64_WIN_SIZE;
|
2020-11-21 02:42:05 +03:00
|
|
|
return true;
|
spapr_pci: Delegate placement of PCI host bridges to machine type
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows. This gives the most control, but is very awkward with 6
mandatory parameters. Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.
The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO). Obviously, for migration we can only change the
locations on a new machine type, however.
This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.
So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass. It's still a bit ugly, but it's about the best we
can do.
For now, this just changes where the calculation is done. It doesn't
change the actual location of the host bridges, or any other behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2016-10-13 02:26:09 +03:00
|
|
|
}
|
|
|
|
|
2017-02-27 17:29:15 +03:00
|
|
|
static ICSState *spapr_ics_get(XICSFabric *dev, int irq)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(dev);
|
2017-02-27 17:29:15 +03:00
|
|
|
|
|
|
|
return ics_valid_irq(spapr->ics, irq) ? spapr->ics : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_ics_resend(XICSFabric *dev)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(dev);
|
2017-02-27 17:29:15 +03:00
|
|
|
|
|
|
|
ics_resend(spapr->ics);
|
|
|
|
}
|
|
|
|
|
2017-08-03 09:28:44 +03:00
|
|
|
static ICPState *spapr_icp_get(XICSFabric *xi, int vcpu_id)
|
2017-02-27 17:29:21 +03:00
|
|
|
{
|
2017-08-09 08:38:56 +03:00
|
|
|
PowerPCCPU *cpu = spapr_find_cpu(vcpu_id);
|
2017-02-27 17:29:21 +03:00
|
|
|
|
2019-01-17 10:53:26 +03:00
|
|
|
return cpu ? spapr_cpu_state(cpu)->icp : NULL;
|
2017-02-27 17:29:21 +03:00
|
|
|
}
|
|
|
|
|
2017-02-27 17:29:32 +03:00
|
|
|
static void spapr_pic_print_info(InterruptStatsProvider *obj,
|
|
|
|
Monitor *mon)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(obj);
|
2017-02-27 17:29:32 +03:00
|
|
|
|
2019-09-26 09:12:05 +03:00
|
|
|
spapr_irq_print_info(spapr, mon);
|
2019-09-12 17:30:09 +03:00
|
|
|
monitor_printf(mon, "irqchip: %s\n",
|
|
|
|
kvm_irqchip_in_kernel() ? "in-kernel" : "emulated");
|
2017-02-27 17:29:32 +03:00
|
|
|
}
|
|
|
|
|
2020-01-06 19:32:07 +03:00
|
|
|
/*
|
|
|
|
* This is a XIVE only operation
|
|
|
|
*/
|
2019-11-25 09:58:10 +03:00
|
|
|
static int spapr_match_nvt(XiveFabric *xfb, uint8_t format,
|
|
|
|
uint8_t nvt_blk, uint32_t nvt_idx,
|
|
|
|
bool cam_ignore, uint8_t priority,
|
|
|
|
uint32_t logic_serv, XiveTCTXMatch *match)
|
|
|
|
{
|
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(xfb);
|
2020-01-06 19:32:07 +03:00
|
|
|
XivePresenter *xptr = XIVE_PRESENTER(spapr->active_intc);
|
2019-11-25 09:58:10 +03:00
|
|
|
XivePresenterClass *xpc = XIVE_PRESENTER_GET_CLASS(xptr);
|
|
|
|
int count;
|
|
|
|
|
|
|
|
count = xpc->match_nvt(xptr, format, nvt_blk, nvt_idx, cam_ignore,
|
|
|
|
priority, logic_serv, match);
|
|
|
|
if (count < 0) {
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When we implement the save and restore of the thread interrupt
|
|
|
|
* contexts in the enter/exit CPU handlers of the machine and the
|
|
|
|
* escalations in QEMU, we should be able to handle non dispatched
|
|
|
|
* vCPUs.
|
|
|
|
*
|
|
|
|
* Until this is done, the sPAPR machine should find at least one
|
|
|
|
* matching context always.
|
|
|
|
*/
|
|
|
|
if (count == 0) {
|
|
|
|
qemu_log_mask(LOG_GUEST_ERROR, "XIVE: NVT %x/%x is not dispatched\n",
|
|
|
|
nvt_blk, nvt_idx);
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2018-02-14 22:40:44 +03:00
|
|
|
int spapr_get_vcpu_id(PowerPCCPU *cpu)
|
2017-08-09 08:38:56 +03:00
|
|
|
{
|
spapr: fix missing CPU core nodes in DT when running with TCG
Commit 5d0fb1508e2d "spapr: consolidate the VCPU id numbering logic
in a single place" introduced a helper to detect thread0 of a virtual
core based on its VCPU id. This is used to create CPU core nodes in
the DT, but it is broken in TCG.
$ qemu-system-ppc64 -nographic -accel tcg -machine dumpdtb=dtb.bin \
-smp cores=16,maxcpus=16,threads=1
$ dtc -f -O dts dtb.bin | grep POWER8
PowerPC,POWER8@0 {
PowerPC,POWER8@8 {
instead of the expected 16 cores that we get with KVM:
$ dtc -f -O dts dtb.bin | grep POWER8
PowerPC,POWER8@0 {
PowerPC,POWER8@8 {
PowerPC,POWER8@10 {
PowerPC,POWER8@18 {
PowerPC,POWER8@20 {
PowerPC,POWER8@28 {
PowerPC,POWER8@30 {
PowerPC,POWER8@38 {
PowerPC,POWER8@40 {
PowerPC,POWER8@48 {
PowerPC,POWER8@50 {
PowerPC,POWER8@58 {
PowerPC,POWER8@60 {
PowerPC,POWER8@68 {
PowerPC,POWER8@70 {
PowerPC,POWER8@78 {
This happens because spapr_get_vcpu_id() maps VCPU ids to
cs->cpu_index in TCG mode. This confuses the code in
spapr_is_thread0_in_vcore(), since it assumes thread0 VCPU
ids to have a spapr->vsmt spacing.
spapr_get_vcpu_id(cpu) % spapr->vsmt == 0
Actually, there's no real reason to expose cs->cpu_index instead
of the VCPU id, since we also generate it with TCG. Also we already
set it explicitly in spapr_set_vcpu_id(), so there's no real reason
either to call kvm_arch_vcpu_id() with KVM.
This patch unifies spapr_get_vcpu_id() to always return the computed
VCPU id both in TCG and KVM. This is one step forward towards KVM<->TCG
migration.
Fixes: 5d0fb1508e2d
Reported-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-02-16 21:58:06 +03:00
|
|
|
return cpu->vcpu_id;
|
2017-08-09 08:38:56 +03:00
|
|
|
}
|
|
|
|
|
2020-09-14 15:35:00 +03:00
|
|
|
bool spapr_set_vcpu_id(PowerPCCPU *cpu, int cpu_index, Error **errp)
|
2018-02-14 22:40:35 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
|
2019-05-18 23:54:22 +03:00
|
|
|
MachineState *ms = MACHINE(spapr);
|
2018-02-14 22:40:35 +03:00
|
|
|
int vcpu_id;
|
|
|
|
|
2018-02-14 22:40:53 +03:00
|
|
|
vcpu_id = spapr_vcpu_id(spapr, cpu_index);
|
2018-02-14 22:40:35 +03:00
|
|
|
|
|
|
|
if (kvm_enabled() && !kvm_vcpu_id_is_valid(vcpu_id)) {
|
|
|
|
error_setg(errp, "Can't create CPU with id %d in KVM", vcpu_id);
|
|
|
|
error_append_hint(errp, "Adjust the number of cpus to %d "
|
|
|
|
"or try to raise the number of threads per core\n",
|
2019-05-18 23:54:22 +03:00
|
|
|
vcpu_id * ms->smp.threads / spapr->vsmt);
|
2020-09-14 15:35:00 +03:00
|
|
|
return false;
|
2018-02-14 22:40:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
cpu->vcpu_id = vcpu_id;
|
2020-09-14 15:35:00 +03:00
|
|
|
return true;
|
2018-02-14 22:40:35 +03:00
|
|
|
}
|
|
|
|
|
2017-08-09 08:38:56 +03:00
|
|
|
PowerPCCPU *spapr_find_cpu(int vcpu_id)
|
|
|
|
{
|
|
|
|
CPUState *cs;
|
|
|
|
|
|
|
|
CPU_FOREACH(cs) {
|
|
|
|
PowerPCCPU *cpu = POWERPC_CPU(cs);
|
|
|
|
|
2018-02-14 22:40:44 +03:00
|
|
|
if (spapr_get_vcpu_id(cpu) == vcpu_id) {
|
2017-08-09 08:38:56 +03:00
|
|
|
return cpu;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2022-02-18 10:34:14 +03:00
|
|
|
static bool spapr_cpu_in_nested(PowerPCCPU *cpu)
|
|
|
|
{
|
2022-02-18 10:34:14 +03:00
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
|
|
|
|
|
|
|
return spapr_cpu->in_nested;
|
2022-02-18 10:34:14 +03:00
|
|
|
}
|
|
|
|
|
2019-07-18 06:42:11 +03:00
|
|
|
static void spapr_cpu_exec_enter(PPCVirtualHypervisor *vhyp, PowerPCCPU *cpu)
|
|
|
|
{
|
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
|
|
|
|
|
|
|
/* These are only called by TCG, KVM maintains dispatch state */
|
|
|
|
|
2019-07-18 06:42:12 +03:00
|
|
|
spapr_cpu->prod = false;
|
2019-07-18 06:42:11 +03:00
|
|
|
if (spapr_cpu->vpa_addr) {
|
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
uint32_t dispatch;
|
|
|
|
|
|
|
|
dispatch = ldl_be_phys(cs->as,
|
|
|
|
spapr_cpu->vpa_addr + VPA_DISPATCH_COUNTER);
|
|
|
|
dispatch++;
|
|
|
|
if ((dispatch & 1) != 0) {
|
|
|
|
qemu_log_mask(LOG_GUEST_ERROR,
|
|
|
|
"VPA: incorrect dispatch counter value for "
|
|
|
|
"dispatched partition %u, correcting.\n", dispatch);
|
|
|
|
dispatch++;
|
|
|
|
}
|
|
|
|
stl_be_phys(cs->as,
|
|
|
|
spapr_cpu->vpa_addr + VPA_DISPATCH_COUNTER, dispatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_cpu_exec_exit(PPCVirtualHypervisor *vhyp, PowerPCCPU *cpu)
|
|
|
|
{
|
|
|
|
SpaprCpuState *spapr_cpu = spapr_cpu_state(cpu);
|
|
|
|
|
|
|
|
if (spapr_cpu->vpa_addr) {
|
|
|
|
CPUState *cs = CPU(cpu);
|
|
|
|
uint32_t dispatch;
|
|
|
|
|
|
|
|
dispatch = ldl_be_phys(cs->as,
|
|
|
|
spapr_cpu->vpa_addr + VPA_DISPATCH_COUNTER);
|
|
|
|
dispatch++;
|
|
|
|
if ((dispatch & 1) != 1) {
|
|
|
|
qemu_log_mask(LOG_GUEST_ERROR,
|
|
|
|
"VPA: incorrect dispatch counter value for "
|
|
|
|
"preempted partition %u, correcting.\n", dispatch);
|
|
|
|
dispatch++;
|
|
|
|
}
|
|
|
|
stl_be_phys(cs->as,
|
|
|
|
spapr_cpu->vpa_addr + VPA_DISPATCH_COUNTER, dispatch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-17 06:40:26 +04:00
|
|
|
static void spapr_machine_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
|
|
|
MachineClass *mc = MACHINE_CLASS(oc);
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(oc);
|
2014-03-17 06:40:27 +04:00
|
|
|
FWPathProviderClass *fwc = FW_PATH_PROVIDER_CLASS(oc);
|
2014-08-20 16:16:36 +04:00
|
|
|
NMIClass *nc = NMI_CLASS(oc);
|
2015-09-01 04:22:35 +03:00
|
|
|
HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
|
2016-10-28 14:06:21 +03:00
|
|
|
PPCVirtualHypervisorClass *vhc = PPC_VIRTUAL_HYPERVISOR_CLASS(oc);
|
2017-02-27 17:29:15 +03:00
|
|
|
XICSFabricClass *xic = XICS_FABRIC_CLASS(oc);
|
2017-02-27 17:29:32 +03:00
|
|
|
InterruptStatsProviderClass *ispc = INTERRUPT_STATS_PROVIDER_CLASS(oc);
|
2019-11-25 09:58:10 +03:00
|
|
|
XiveFabricClass *xfc = XIVE_FABRIC_CLASS(oc);
|
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 08:51:55 +03:00
|
|
|
VofMachineIfClass *vmc = VOF_MACHINE_CLASS(oc);
|
2014-04-09 21:34:53 +04:00
|
|
|
|
2015-12-07 06:29:35 +03:00
|
|
|
mc->desc = "pSeries Logical Partition (PAPR compliant)";
|
2018-08-10 15:40:27 +03:00
|
|
|
mc->ignore_boot_device_suffixes = true;
|
2015-12-07 06:27:21 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We set up the default / latest behaviour here. The class_init
|
|
|
|
* functions for the specific versioned machine types can override
|
|
|
|
* these details for backwards compatibility
|
|
|
|
*/
|
2017-12-08 04:47:34 +03:00
|
|
|
mc->init = spapr_machine_init;
|
|
|
|
mc->reset = spapr_machine_reset;
|
2014-04-09 21:34:53 +04:00
|
|
|
mc->block_default_type = IF_SCSI;
|
spapr.c: do not use MachineClass::max_cpus to limit CPUs
Up to this patch, 'max_cpus' value is hardcoded to 1024 (commit
6244bb7e5811). In theory this patch would simply bump it to 2048, since
it's the default NR_CPUS kernel setting for ppc64 servers nowadays, but
the whole mechanic of MachineClass:max_cpus is flawed for the pSeries
machine. The two supported accelerators, KVM and TCG, can live without
it.
TCG guests don't have a theoretical limit. The user must be free to
emulate as many CPUs as the hardware is capable of. And even if there
were a limit, max_cpus is not the proper way to report it since it's a
common value checked by SMP code in machine_smp_parse() for KVM as well.
For KVM guests, the proper way to limit KVM CPUs is by host
configuration via NR_CPUS, not a QEMU hardcoded value. There is no
technical reason for a pSeries QEMU guest to forcefully stay below
NR_CPUS.
This hardcoded value also disregard hosts that might have a lower
NR_CPUS limit, say 512. In this case, machine.c:machine_smp_parse() will
allow a 1024 value to pass, but then kvm_init() will complain about it
because it will exceed NR_CPUS:
Number of SMP cpus requested (1024) exceeds the maximum cpus supported
by KVM (512)
A better 'max_cpus' value would consider host settings, but
MachineClass::max_cpus is defined well before machine_init() and
kvm_init(). We can't check for KVM limits because it's too soon, so we
end up making a guess.
This patch makes MachineClass:max_cpus settings innocuous by setting it
to INT32_MAX. machine.c:machine_smp_parse() will not fail the
verification based on max_cpus, letting kvm_init() do the checking with
actual host settings. And TCG guests get to do whatever the hardware is
capable of emulating.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210408204049.221802-2-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-04-08 23:40:48 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Setting max_cpus to INT32_MAX. Both KVM and TCG max_cpus values
|
|
|
|
* should be limited by the host capability instead of hardcoded.
|
|
|
|
* max_cpus for KVM guests will be checked in kvm_init(), and TCG
|
|
|
|
* guests are welcome to have as many CPUs as the host are capable
|
|
|
|
* of emulate.
|
|
|
|
*/
|
|
|
|
mc->max_cpus = INT32_MAX;
|
|
|
|
|
2014-04-09 21:34:53 +04:00
|
|
|
mc->no_parallel = 1;
|
2015-03-18 15:30:44 +03:00
|
|
|
mc->default_boot_order = "";
|
2018-06-25 15:41:57 +03:00
|
|
|
mc->default_ram_size = 512 * MiB;
|
2020-02-19 19:09:41 +03:00
|
|
|
mc->default_ram_id = "ppc_spapr.ram";
|
2018-07-02 22:13:45 +03:00
|
|
|
mc->default_display = "std";
|
2014-04-09 21:34:53 +04:00
|
|
|
mc->kvm_type = spapr_kvm_type;
|
2017-11-25 18:16:08 +03:00
|
|
|
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SPAPR_PCI_HOST_BRIDGE);
|
2015-07-24 11:35:13 +03:00
|
|
|
mc->pci_allow_0_address = true;
|
2018-05-10 20:10:56 +03:00
|
|
|
assert(!mc->get_hotplug_handler);
|
2016-09-12 10:57:20 +03:00
|
|
|
mc->get_hotplug_handler = spapr_get_hotplug_handler;
|
2016-06-10 03:59:03 +03:00
|
|
|
hc->pre_plug = spapr_machine_device_pre_plug;
|
2015-09-01 04:22:35 +03:00
|
|
|
hc->plug = spapr_machine_device_plug;
|
2017-05-10 14:29:45 +03:00
|
|
|
mc->cpu_index_to_instance_props = spapr_cpu_index_to_props;
|
2017-06-01 13:53:28 +03:00
|
|
|
mc->get_default_cpu_node_id = spapr_get_default_cpu_node_id;
|
2017-02-10 13:18:49 +03:00
|
|
|
mc->possible_cpu_arch_ids = spapr_possible_cpu_arch_ids;
|
2016-10-27 05:20:30 +03:00
|
|
|
hc->unplug_request = spapr_machine_device_unplug_request;
|
2018-06-08 15:48:14 +03:00
|
|
|
hc->unplug = spapr_machine_device_unplug;
|
2014-04-09 21:34:50 +04:00
|
|
|
|
2015-12-07 06:27:21 +03:00
|
|
|
smc->dr_lmb_enabled = true;
|
2018-12-21 03:34:48 +03:00
|
|
|
smc->update_dt_enabled = true;
|
2023-05-15 19:02:01 +03:00
|
|
|
mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power9_v2.2");
|
2017-02-10 13:20:57 +03:00
|
|
|
mc->has_hotpluggable_cpus = true;
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
mc->nvdimm_supported = true;
|
2017-07-12 10:53:17 +03:00
|
|
|
smc->resize_hpt_default = SPAPR_RESIZE_HPT_ENABLED;
|
2014-03-17 06:40:27 +04:00
|
|
|
fwc->get_dev_path = spapr_get_fw_dev_path;
|
2014-08-20 16:16:36 +04:00
|
|
|
nc->nmi_monitor_handler = spapr_nmi;
|
spapr_pci: Delegate placement of PCI host bridges to machine type
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge device: first
it can be done fully manually, specifying the locations and sizes of all
the IO windows. This gives the most control, but is very awkward with 6
mandatory parameters. Alternatively just an "index" can be specified
which essentially selects from an array of predefined PHB locations.
The PHB at index 0 is automatically created as the default PHB.
The current set of default locations causes some problems for guests with
large RAM (> 1 TiB) or PCI devices with very large BARs (e.g. big nVidia
GPGPU cards via VFIO). Obviously, for migration we can only change the
locations on a new machine type, however.
This is awkward, because the placement is currently decided within the
spapr-pci-host-bridge code, so it breaks abstraction to look inside the
machine type version.
So, this patch delegates the "default mode" PHB placement from the
spapr-pci-host-bridge device back to the machine type via a public method
in sPAPRMachineClass. It's still a bit ugly, but it's about the best we
can do.
For now, this just changes where the calculation is done. It doesn't
change the actual location of the host bridges, or any other behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2016-10-13 02:26:09 +03:00
|
|
|
smc->phb_placement = spapr_phb_placement;
|
2022-02-18 10:34:14 +03:00
|
|
|
vhc->cpu_in_nested = spapr_cpu_in_nested;
|
2022-02-18 10:34:14 +03:00
|
|
|
vhc->deliver_hv_excp = spapr_exit_nested;
|
2016-10-28 14:06:21 +03:00
|
|
|
vhc->hypercall = emulate_spapr_hypercall;
|
2017-02-23 03:39:18 +03:00
|
|
|
vhc->hpt_mask = spapr_hpt_mask;
|
|
|
|
vhc->map_hptes = spapr_map_hptes;
|
|
|
|
vhc->unmap_hptes = spapr_unmap_hptes;
|
2019-04-11 11:00:01 +03:00
|
|
|
vhc->hpte_set_c = spapr_hpte_set_c;
|
|
|
|
vhc->hpte_set_r = spapr_hpte_set_r;
|
2019-02-15 20:00:27 +03:00
|
|
|
vhc->get_pate = spapr_get_pate;
|
2017-09-25 14:00:02 +03:00
|
|
|
vhc->encode_hpt_for_kvm_pr = spapr_encode_hpt_for_kvm_pr;
|
2019-07-18 06:42:11 +03:00
|
|
|
vhc->cpu_exec_enter = spapr_cpu_exec_enter;
|
|
|
|
vhc->cpu_exec_exit = spapr_cpu_exec_exit;
|
2017-02-27 17:29:15 +03:00
|
|
|
xic->ics_get = spapr_ics_get;
|
|
|
|
xic->ics_resend = spapr_ics_resend;
|
2017-02-27 17:29:21 +03:00
|
|
|
xic->icp_get = spapr_icp_get;
|
2017-02-27 17:29:32 +03:00
|
|
|
ispc->print_info = spapr_pic_print_info;
|
2017-03-21 13:25:42 +03:00
|
|
|
/* Force NUMA node memory size to be a multiple of
|
|
|
|
* SPAPR_MEMORY_BLOCK_SIZE (256M) since that's the granularity
|
|
|
|
* in which LMBs are represented and hot-added
|
|
|
|
*/
|
|
|
|
mc->numa_mem_align_shift = 28;
|
2019-09-05 11:32:38 +03:00
|
|
|
mc->auto_enable_numa = true;
|
spapr: Capabilities infrastructure
Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor. PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.
In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.
Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.
We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability. But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.
This introduces an infrastructure for defining "sPAPR capabilities". These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.
The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations). If not we simply fail, rather than silently modifying the
advertised featureset to the guest.
This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
2017-12-08 02:35:35 +03:00
|
|
|
|
2018-01-12 08:33:43 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_ON;
|
2019-03-01 07:46:09 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_WORKAROUND;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_WORKAROUND;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_WORKAROUND;
|
2018-03-16 11:19:13 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB */
|
2018-10-08 06:25:39 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
|
2019-03-01 05:43:17 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
|
spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machine
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
mitigation is "count cache disabled", which is configured with:
-machine cap-ibs=fixed-ccd
However, this option isn't available on DD2.3 CPUs with KVM, because they
don't have the count cache disabled.
For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured
with:
-machine cap-ibs=workaround,cap-ccf-assist=on
However this option isn't available on DD2.2 CPUs with KVM, because they
don't have the special CCF assist instruction this relies on.
On current machine types, we default to "count cache flush w/o assist",
that is:
-machine cap-ibs=workaround,cap-ccf-assist=off
This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a
fairly significant performance impact.
It turns out we can do better. The special instruction that CCF assist
uses to trigger a count cache flush is a no-op on earlier CPUs, rather than
trapping or causing other badness. It doesn't, of itself, implement the
mitigation, but *if* we have count-cache-disabled, then the count cache
flush is unnecessary, and so using the count cache flush mitigation is
harmless.
Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by
default. Along with that, suppress throwing an error if cap-ccf-assist
is selected but KVM doesn't support it, as long as KVM *is* giving us
count-cache-disabled. To allow TCG to work out of the box, even though it
doesn't implement the ccf flush assist, downgrade the error in that case to
a warning. This matches several Spectre mitigations where we allow TCG
to operate for debugging, since we don't really make guarantees about TCG
security properties anyway.
While we're there, make the TCG warning for this case match that for other
mitigations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-01-30 02:28:56 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_ON;
|
2020-03-16 17:26:07 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_FWNMI] = SPAPR_CAP_ON;
|
2021-07-06 14:24:40 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_RPT_INVALIDATE] = SPAPR_CAP_OFF;
|
2023-05-15 19:02:16 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This cap specifies whether the AIL 3 mode for
|
|
|
|
* H_SET_RESOURCE is supported. The default is modified
|
|
|
|
* by default_caps_with_cpu().
|
|
|
|
*/
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_AIL_MODE_3] = SPAPR_CAP_ON;
|
2020-05-05 18:29:23 +03:00
|
|
|
spapr_caps_add_properties(smc);
|
2019-05-22 10:40:16 +03:00
|
|
|
smc->irq = &spapr_irq_dual;
|
2019-02-19 20:18:54 +03:00
|
|
|
smc->dr_phb_enabled = true;
|
2019-07-19 07:37:34 +03:00
|
|
|
smc->linux_pci_probe = true;
|
2019-10-03 15:02:00 +03:00
|
|
|
smc->smp_threads_vsmt = true;
|
2019-09-27 06:54:23 +03:00
|
|
|
smc->nr_xirqs = SPAPR_NR_XIRQS;
|
2019-11-25 09:58:10 +03:00
|
|
|
xfc->match_nvt = spapr_match_nvt;
|
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 08:51:55 +03:00
|
|
|
vmc->client_architecture_support = spapr_vof_client_architecture_support;
|
|
|
|
vmc->quiesce = spapr_vof_quiesce;
|
|
|
|
vmc->setprop = spapr_vof_setprop;
|
2014-03-17 06:40:26 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo spapr_machine_info = {
|
|
|
|
.name = TYPE_SPAPR_MACHINE,
|
|
|
|
.parent = TYPE_MACHINE,
|
2014-09-08 09:30:31 +04:00
|
|
|
.abstract = true,
|
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 07:35:37 +03:00
|
|
|
.instance_size = sizeof(SpaprMachineState),
|
2017-12-08 04:47:34 +03:00
|
|
|
.instance_init = spapr_instance_init,
|
2015-12-28 09:38:26 +03:00
|
|
|
.instance_finalize = spapr_machine_finalizefn,
|
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 07:35:37 +03:00
|
|
|
.class_size = sizeof(SpaprMachineClass),
|
2014-03-17 06:40:26 +04:00
|
|
|
.class_init = spapr_machine_class_init,
|
2014-03-17 06:40:27 +04:00
|
|
|
.interfaces = (InterfaceInfo[]) {
|
|
|
|
{ TYPE_FW_PATH_PROVIDER },
|
2014-08-20 16:16:36 +04:00
|
|
|
{ TYPE_NMI },
|
2015-09-01 04:22:35 +03:00
|
|
|
{ TYPE_HOTPLUG_HANDLER },
|
2016-10-28 14:06:21 +03:00
|
|
|
{ TYPE_PPC_VIRTUAL_HYPERVISOR },
|
2017-02-27 17:29:15 +03:00
|
|
|
{ TYPE_XICS_FABRIC },
|
2017-02-27 17:29:32 +03:00
|
|
|
{ TYPE_INTERRUPT_STATS_PROVIDER },
|
2019-11-25 09:58:10 +03:00
|
|
|
{ TYPE_XIVE_FABRIC },
|
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 08:51:55 +03:00
|
|
|
{ TYPE_VOF_MACHINE_IF },
|
2014-03-17 06:40:27 +04:00
|
|
|
{ }
|
|
|
|
},
|
2014-03-17 06:40:26 +04:00
|
|
|
};
|
|
|
|
|
2020-02-07 09:46:37 +03:00
|
|
|
static void spapr_machine_latest_class_options(MachineClass *mc)
|
|
|
|
{
|
|
|
|
mc->alias = "pseries";
|
2020-02-07 19:19:47 +03:00
|
|
|
mc->is_default = true;
|
2020-02-07 09:46:37 +03:00
|
|
|
}
|
|
|
|
|
2015-12-07 06:25:50 +03:00
|
|
|
#define DEFINE_SPAPR_MACHINE(suffix, verstr, latest) \
|
2015-12-07 06:23:20 +03:00
|
|
|
static void spapr_machine_##suffix##_class_init(ObjectClass *oc, \
|
|
|
|
void *data) \
|
|
|
|
{ \
|
|
|
|
MachineClass *mc = MACHINE_CLASS(oc); \
|
|
|
|
spapr_machine_##suffix##_class_options(mc); \
|
2015-12-07 06:25:50 +03:00
|
|
|
if (latest) { \
|
2020-02-07 09:46:37 +03:00
|
|
|
spapr_machine_latest_class_options(mc); \
|
2015-12-07 06:25:50 +03:00
|
|
|
} \
|
2015-12-07 06:23:20 +03:00
|
|
|
} \
|
|
|
|
static const TypeInfo spapr_machine_##suffix##_info = { \
|
|
|
|
.name = MACHINE_TYPE_NAME("pseries-" verstr), \
|
|
|
|
.parent = TYPE_SPAPR_MACHINE, \
|
|
|
|
.class_init = spapr_machine_##suffix##_class_init, \
|
|
|
|
}; \
|
|
|
|
static void spapr_machine_register_##suffix(void) \
|
|
|
|
{ \
|
|
|
|
type_register(&spapr_machine_##suffix##_info); \
|
|
|
|
} \
|
2016-02-16 23:59:04 +03:00
|
|
|
type_init(spapr_machine_register_##suffix)
|
2015-12-07 06:23:20 +03:00
|
|
|
|
2023-11-20 12:42:59 +03:00
|
|
|
/*
|
|
|
|
* pseries-9.0
|
|
|
|
*/
|
|
|
|
static void spapr_machine_9_0_class_options(MachineClass *mc)
|
|
|
|
{
|
|
|
|
/* Defaults for the latest behaviour inherited from the base class */
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_SPAPR_MACHINE(9_0, "9.0", true);
|
|
|
|
|
2023-07-18 17:22:35 +03:00
|
|
|
/*
|
|
|
|
* pseries-8.2
|
|
|
|
*/
|
|
|
|
static void spapr_machine_8_2_class_options(MachineClass *mc)
|
|
|
|
{
|
2023-11-20 12:42:59 +03:00
|
|
|
spapr_machine_9_0_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_8_2, hw_compat_8_2_len);
|
2023-07-18 17:22:35 +03:00
|
|
|
}
|
|
|
|
|
2023-11-20 12:42:59 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(8_2, "8.2", false);
|
2023-07-18 17:22:35 +03:00
|
|
|
|
2023-03-14 20:30:09 +03:00
|
|
|
/*
|
|
|
|
* pseries-8.1
|
|
|
|
*/
|
|
|
|
static void spapr_machine_8_1_class_options(MachineClass *mc)
|
|
|
|
{
|
2023-07-18 17:22:35 +03:00
|
|
|
spapr_machine_8_2_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_8_1, hw_compat_8_1_len);
|
2023-03-14 20:30:09 +03:00
|
|
|
}
|
|
|
|
|
2023-07-18 17:22:35 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(8_1, "8.1", false);
|
2023-03-14 20:30:09 +03:00
|
|
|
|
2022-12-12 18:21:44 +03:00
|
|
|
/*
|
|
|
|
* pseries-8.0
|
|
|
|
*/
|
|
|
|
static void spapr_machine_8_0_class_options(MachineClass *mc)
|
|
|
|
{
|
2023-03-14 20:30:09 +03:00
|
|
|
spapr_machine_8_1_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_8_0, hw_compat_8_0_len);
|
2022-12-12 18:21:44 +03:00
|
|
|
}
|
|
|
|
|
2023-03-14 20:30:09 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(8_0, "8.0", false);
|
2022-12-12 18:21:44 +03:00
|
|
|
|
2022-07-27 15:17:55 +03:00
|
|
|
/*
|
|
|
|
* pseries-7.2
|
|
|
|
*/
|
|
|
|
static void spapr_machine_7_2_class_options(MachineClass *mc)
|
|
|
|
{
|
2022-12-12 18:21:44 +03:00
|
|
|
spapr_machine_8_0_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_7_2, hw_compat_7_2_len);
|
2022-07-27 15:17:55 +03:00
|
|
|
}
|
|
|
|
|
2022-12-12 18:21:44 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(7_2, "7.2", false);
|
2022-07-27 15:17:55 +03:00
|
|
|
|
2022-03-16 17:55:21 +03:00
|
|
|
/*
|
|
|
|
* pseries-7.1
|
|
|
|
*/
|
|
|
|
static void spapr_machine_7_1_class_options(MachineClass *mc)
|
|
|
|
{
|
2022-07-27 15:17:55 +03:00
|
|
|
spapr_machine_7_2_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_7_1, hw_compat_7_1_len);
|
2022-03-16 17:55:21 +03:00
|
|
|
}
|
|
|
|
|
2022-07-27 15:17:55 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(7_1, "7.1", false);
|
2022-03-16 17:55:21 +03:00
|
|
|
|
2021-12-17 17:39:48 +03:00
|
|
|
/*
|
|
|
|
* pseries-7.0
|
|
|
|
*/
|
|
|
|
static void spapr_machine_7_0_class_options(MachineClass *mc)
|
|
|
|
{
|
2022-03-16 17:55:21 +03:00
|
|
|
spapr_machine_7_1_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_7_0, hw_compat_7_0_len);
|
2021-12-17 17:39:48 +03:00
|
|
|
}
|
|
|
|
|
2022-03-16 17:55:21 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(7_0, "7.0", false);
|
2021-12-17 17:39:48 +03:00
|
|
|
|
2021-08-31 04:54:26 +03:00
|
|
|
/*
|
|
|
|
* pseries-6.2
|
|
|
|
*/
|
|
|
|
static void spapr_machine_6_2_class_options(MachineClass *mc)
|
|
|
|
{
|
2021-12-17 17:39:48 +03:00
|
|
|
spapr_machine_7_0_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_6_2, hw_compat_6_2_len);
|
2021-08-31 04:54:26 +03:00
|
|
|
}
|
|
|
|
|
2021-12-17 17:39:48 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(6_2, "6.2", false);
|
2021-08-31 04:54:26 +03:00
|
|
|
|
2021-03-31 14:19:00 +03:00
|
|
|
/*
|
|
|
|
* pseries-6.1
|
|
|
|
*/
|
|
|
|
static void spapr_machine_6_1_class_options(MachineClass *mc)
|
|
|
|
{
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
|
|
|
|
2021-08-31 04:54:26 +03:00
|
|
|
spapr_machine_6_2_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len);
|
spapr_numa.c: FORM2 NUMA affinity support
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Another feature is its extensibility. This base
support contains the facilities for NUMA distance assignment, but in the
future more facilities will be added for latency, performance, bandwidth
and so on.
This patch implements the base FORM2 affinity support as follows:
- the use of FORM2 associativity is indicated by using bit 2 of byte 5
of ibm,architecture-vec-5. A FORM2 aware guest can choose to use FORM1
or FORM2 affinity. Setting both forms will default to FORM2. We're not
advertising FORM2 for pseries-6.1 and older machine versions to prevent
guest visible changes in those;
- ibm,associativity-reference-points has a new semantic. Instead of
being used to calculate distances via NUMA levels, it's now used to
indicate the primary domain index in the ibm,associativity domain of
each resource. In our case it's set to {0x4}, matching the position
where we already place logical_domain_id;
- two new RTAS DT artifacts are introduced: ibm,numa-lookup-index-table
and ibm,numa-distance-table. The index table is used to list all the
NUMA logical domains of the platform, in ascending order, and allows for
spartial NUMA configurations (although QEMU ATM doesn't support that).
ibm,numa-distance-table is an array that contains all the distances from
the first NUMA node to all other nodes, then the second NUMA node
distances to all other nodes and so on;
- get_max_dist_ref_points(), get_numa_assoc_size() and get_associativity()
now checks for OV5_FORM2_AFFINITY and returns FORM2 values if the guest
selected FORM2 affinity during CAS.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210920174947.556324-7-danielhb413@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-09-20 20:49:46 +03:00
|
|
|
smc->pre_6_2_numa_affinity = true;
|
2021-09-29 05:58:14 +03:00
|
|
|
mc->smp_props.prefer_sockets = true;
|
2021-03-31 14:19:00 +03:00
|
|
|
}
|
|
|
|
|
2021-08-31 04:54:26 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(6_1, "6.1", false);
|
2021-03-31 14:19:00 +03:00
|
|
|
|
2020-11-09 20:39:28 +03:00
|
|
|
/*
|
|
|
|
* pseries-6.0
|
|
|
|
*/
|
|
|
|
static void spapr_machine_6_0_class_options(MachineClass *mc)
|
|
|
|
{
|
2021-03-31 14:19:00 +03:00
|
|
|
spapr_machine_6_1_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len);
|
2020-11-09 20:39:28 +03:00
|
|
|
}
|
|
|
|
|
2021-03-31 14:19:00 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(6_0, "6.0", false);
|
2020-11-09 20:39:28 +03:00
|
|
|
|
2020-08-19 17:40:16 +03:00
|
|
|
/*
|
|
|
|
* pseries-5.2
|
|
|
|
*/
|
|
|
|
static void spapr_machine_5_2_class_options(MachineClass *mc)
|
|
|
|
{
|
2020-11-09 20:39:28 +03:00
|
|
|
spapr_machine_6_0_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_5_2, hw_compat_5_2_len);
|
2020-08-19 17:40:16 +03:00
|
|
|
}
|
|
|
|
|
2020-11-09 20:39:28 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(5_2, "5.2", false);
|
2020-08-19 17:40:16 +03:00
|
|
|
|
2020-04-29 17:46:05 +03:00
|
|
|
/*
|
|
|
|
* pseries-5.1
|
|
|
|
*/
|
|
|
|
static void spapr_machine_5_1_class_options(MachineClass *mc)
|
|
|
|
{
|
2020-10-07 20:28:45 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
|
|
|
|
2020-08-19 17:40:16 +03:00
|
|
|
spapr_machine_5_2_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_5_1, hw_compat_5_1_len);
|
2020-10-07 20:28:45 +03:00
|
|
|
smc->pre_5_2_numa_associativity = true;
|
2020-04-29 17:46:05 +03:00
|
|
|
}
|
|
|
|
|
2020-08-19 17:40:16 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(5_1, "5.1", false);
|
2020-04-29 17:46:05 +03:00
|
|
|
|
2019-11-12 13:48:11 +03:00
|
|
|
/*
|
|
|
|
* pseries-5.0
|
|
|
|
*/
|
|
|
|
static void spapr_machine_5_0_class_options(MachineClass *mc)
|
|
|
|
{
|
2020-07-17 01:56:55 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
|
|
|
static GlobalProperty compat[] = {
|
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "pre-5.1-associativity", "on" },
|
|
|
|
};
|
|
|
|
|
2020-04-29 17:46:05 +03:00
|
|
|
spapr_machine_5_1_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_5_0, hw_compat_5_0_len);
|
2020-07-17 01:56:55 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2020-06-09 16:56:35 +03:00
|
|
|
mc->numa_mem_supported = true;
|
2020-07-17 01:56:55 +03:00
|
|
|
smc->pre_5_1_assoc_refpoints = true;
|
2019-11-12 13:48:11 +03:00
|
|
|
}
|
|
|
|
|
2020-04-29 17:46:05 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(5_0, "5.0", false);
|
2019-11-12 13:48:11 +03:00
|
|
|
|
2019-07-24 13:35:24 +03:00
|
|
|
/*
|
|
|
|
* pseries-4.2
|
|
|
|
*/
|
|
|
|
static void spapr_machine_4_2_class_options(MachineClass *mc)
|
|
|
|
{
|
spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machine
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
mitigation is "count cache disabled", which is configured with:
-machine cap-ibs=fixed-ccd
However, this option isn't available on DD2.3 CPUs with KVM, because they
don't have the count cache disabled.
For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured
with:
-machine cap-ibs=workaround,cap-ccf-assist=on
However this option isn't available on DD2.2 CPUs with KVM, because they
don't have the special CCF assist instruction this relies on.
On current machine types, we default to "count cache flush w/o assist",
that is:
-machine cap-ibs=workaround,cap-ccf-assist=off
This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a
fairly significant performance impact.
It turns out we can do better. The special instruction that CCF assist
uses to trigger a count cache flush is a no-op on earlier CPUs, rather than
trapping or causing other badness. It doesn't, of itself, implement the
mitigation, but *if* we have count-cache-disabled, then the count cache
flush is unnecessary, and so using the count cache flush mitigation is
harmless.
Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by
default. Along with that, suppress throwing an error if cap-ccf-assist
is selected but KVM doesn't support it, as long as KVM *is* giving us
count-cache-disabled. To allow TCG to work out of the box, even though it
doesn't implement the ccf flush assist, downgrade the error in that case to
a warning. This matches several Spectre mitigations where we allow TCG
to operate for debugging, since we don't really make guarantees about TCG
security properties anyway.
While we're there, make the TCG warning for this case match that for other
mitigations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-01-30 02:28:56 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
|
|
|
|
2019-11-12 13:48:11 +03:00
|
|
|
spapr_machine_5_0_class_options(mc);
|
2019-11-05 21:22:17 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_4_2, hw_compat_4_2_len);
|
spapr: Enable DD2.3 accelerated count cache flush in pseries-5.0 machine
For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
mitigation is "count cache disabled", which is configured with:
-machine cap-ibs=fixed-ccd
However, this option isn't available on DD2.3 CPUs with KVM, because they
don't have the count cache disabled.
For POWER9 DD2.3 cpus, it is "count cache flush with assist", configured
with:
-machine cap-ibs=workaround,cap-ccf-assist=on
However this option isn't available on DD2.2 CPUs with KVM, because they
don't have the special CCF assist instruction this relies on.
On current machine types, we default to "count cache flush w/o assist",
that is:
-machine cap-ibs=workaround,cap-ccf-assist=off
This runs, with mitigation on both DD2.2 and DD2.3 host cpus, but has a
fairly significant performance impact.
It turns out we can do better. The special instruction that CCF assist
uses to trigger a count cache flush is a no-op on earlier CPUs, rather than
trapping or causing other badness. It doesn't, of itself, implement the
mitigation, but *if* we have count-cache-disabled, then the count cache
flush is unnecessary, and so using the count cache flush mitigation is
harmless.
Therefore for the new pseries-5.0 machine type, enable cap-ccf-assist by
default. Along with that, suppress throwing an error if cap-ccf-assist
is selected but KVM doesn't support it, as long as KVM *is* giving us
count-cache-disabled. To allow TCG to work out of the box, even though it
doesn't implement the ccf flush assist, downgrade the error in that case to
a warning. This matches several Spectre mitigations where we allow TCG
to operate for debugging, since we don't really make guarantees about TCG
security properties anyway.
While we're there, make the TCG warning for this case match that for other
mitigations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
2020-01-30 02:28:56 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_OFF;
|
2020-03-16 17:26:07 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_FWNMI] = SPAPR_CAP_OFF;
|
spapr: Don't clamp RMA to 16GiB on new machine types
In spapr_machine_init() we clamp the size of the RMA to 16GiB and the
comment saying why doesn't make a whole lot of sense. In fact, this was
done because the real mode handling code elsewhere limited the RMA in TCG
mode to the maximum value configurable in LPCR[RMLS], 16GiB.
But,
* Actually LPCR[RMLS] has been able to encode a 256GiB size for a very
long time, we just didn't implement it properly in the softmmu
* LPCR[RMLS] shouldn't really be relevant anyway, it only was because we
used to abuse the RMOR based translation mode in order to handle the
fact that we're not modelling the hypervisor parts of the cpu
We've now removed those limitations in the modelling so the 16GiB clamp no
longer serves a function. However, we can't just remove the limit
universally: that would break migration to earlier qemu versions, where
the 16GiB RMLS limit still applies, no matter how bad the reasons for it
are.
So, we replace the 16GiB clamp, with a clamp to a limit defined in the
machine type class. We set it to 16 GiB for machine types 4.2 and earlier,
but set it to 0 meaning unlimited for the new 5.0 machine type.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-19 12:53:13 +03:00
|
|
|
smc->rma_limit = 16 * GiB;
|
spapr: Add NVDIMM device support
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node and sends a hotplug
interrupt to the guest. Guest is expected to undertake the normal
DR resource add path in response and start issuing PAPR SCM hcalls.
The device support is verified based on the machine version unlike x86.
This is how it can be used ..
Ex :
For coldplug, the device to be added in qemu command line as shown below
-object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
-device nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
For hotplug, the device to be added from monitor as below
object_add memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm0,share=yes,size=1073872896
device_add nvdimm,label-size=128k,uuid=75a3cdd7-6a2f-4791-8d15-fe0a920e8e9e,memdev=memnvdimm0,id=nvdimm0,slot=0
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
[Early implementation]
Message-Id: <158131058078.2897.12767731856697459923.stgit@lep8c.aus.stglabs.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-10 07:56:31 +03:00
|
|
|
mc->nvdimm_supported = false;
|
2019-07-24 13:35:24 +03:00
|
|
|
}
|
|
|
|
|
2019-11-12 13:48:11 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(4_2, "4.2", false);
|
2019-07-24 13:35:24 +03:00
|
|
|
|
2019-04-11 13:20:25 +03:00
|
|
|
/*
|
|
|
|
* pseries-4.1
|
|
|
|
*/
|
|
|
|
static void spapr_machine_4_1_class_options(MachineClass *mc)
|
|
|
|
{
|
2019-07-19 07:37:34 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2019-07-05 08:03:05 +03:00
|
|
|
static GlobalProperty compat[] = {
|
|
|
|
/* Only allow 4kiB and 64kiB IOMMU pagesizes */
|
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "pgsz", "0x11000" },
|
|
|
|
};
|
|
|
|
|
2019-07-24 13:35:24 +03:00
|
|
|
spapr_machine_4_2_class_options(mc);
|
2019-07-19 07:37:34 +03:00
|
|
|
smc->linux_pci_probe = false;
|
2019-10-03 15:02:00 +03:00
|
|
|
smc->smp_threads_vsmt = false;
|
2019-07-24 13:35:24 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_4_1, hw_compat_4_1_len);
|
2019-07-05 08:03:05 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2019-04-11 13:20:25 +03:00
|
|
|
}
|
|
|
|
|
2019-07-24 13:35:24 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(4_1, "4.1", false);
|
2019-04-11 13:20:25 +03:00
|
|
|
|
2018-12-04 19:27:16 +03:00
|
|
|
/*
|
|
|
|
* pseries-4.0
|
|
|
|
*/
|
2020-11-21 02:42:05 +03:00
|
|
|
static bool phb_placement_4_0(SpaprMachineState *spapr, uint32_t index,
|
spapr: Support NVIDIA V100 GPU with NVLink2
NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
implements special regions for such GPUs and emulates an NVLink bridge.
NVLink2-enabled POWER9 CPUs also provide address translation services
which includes an ATS shootdown (ATSD) register exported via the NVLink
bridge device.
This adds a quirk to VFIO to map the GPU memory and create an MR;
the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
this to get the MR and map it to the system address space.
Another quirk does the same for ATSD.
This adds additional steps to sPAPR PHB setup:
1. Search for specific GPUs and NPUs, collect findings in
sPAPRPHBState::nvgpus, manage system address space mappings;
2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
"memory-block", "link-speed" to advertise the NVLink2 function to
the guest;
3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
4. Add new memory blocks (with extra "linux,memory-usable" to prevent
the guest OS from accessing the new memory until it is onlined) and
npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
uses it for link discovery.
This allocates space for GPU RAM and ATSD like we do for MMIOs by
adding 2 new parameters to the phb_placement() hook. Older machine types
set these to zero.
This puts new memory nodes in a separate NUMA node to as the GPU RAM
needs to be configured equally distant from any other node in the system.
Unlike the host setup which assigns numa ids from 255 downwards, this
adds new NUMA nodes after the user configures nodes or from 1 if none
were configured.
This adds requirement similar to EEH - one IOMMU group per vPHB.
The reason for this is that ATSD registers belong to a physical NPU
so they cannot invalidate translations on GPUs attached to another NPU.
It is guaranteed by the host platform as it does not mix NVLink bridges
or GPUs from different NPU in the same IOMMU group. If more than one
IOMMU group is detected on a vPHB, this disables ATSD support for that
vPHB and prints a warning.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[aw: for vfio portions]
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <20190312082103.130561-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12 11:21:03 +03:00
|
|
|
uint64_t *buid, hwaddr *pio,
|
|
|
|
hwaddr *mmio32, hwaddr *mmio64,
|
2023-09-18 12:17:17 +03:00
|
|
|
unsigned n_dma, uint32_t *liobns, Error **errp)
|
spapr: Support NVIDIA V100 GPU with NVLink2
NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
implements special regions for such GPUs and emulates an NVLink bridge.
NVLink2-enabled POWER9 CPUs also provide address translation services
which includes an ATS shootdown (ATSD) register exported via the NVLink
bridge device.
This adds a quirk to VFIO to map the GPU memory and create an MR;
the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
this to get the MR and map it to the system address space.
Another quirk does the same for ATSD.
This adds additional steps to sPAPR PHB setup:
1. Search for specific GPUs and NPUs, collect findings in
sPAPRPHBState::nvgpus, manage system address space mappings;
2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
"memory-block", "link-speed" to advertise the NVLink2 function to
the guest;
3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
4. Add new memory blocks (with extra "linux,memory-usable" to prevent
the guest OS from accessing the new memory until it is onlined) and
npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
uses it for link discovery.
This allocates space for GPU RAM and ATSD like we do for MMIOs by
adding 2 new parameters to the phb_placement() hook. Older machine types
set these to zero.
This puts new memory nodes in a separate NUMA node to as the GPU RAM
needs to be configured equally distant from any other node in the system.
Unlike the host setup which assigns numa ids from 255 downwards, this
adds new NUMA nodes after the user configures nodes or from 1 if none
were configured.
This adds requirement similar to EEH - one IOMMU group per vPHB.
The reason for this is that ATSD registers belong to a physical NPU
so they cannot invalidate translations on GPUs attached to another NPU.
It is guaranteed by the host platform as it does not mix NVLink bridges
or GPUs from different NPU in the same IOMMU group. If more than one
IOMMU group is detected on a vPHB, this disables ATSD support for that
vPHB and prints a warning.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[aw: for vfio portions]
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <20190312082103.130561-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12 11:21:03 +03:00
|
|
|
{
|
2020-11-21 02:42:05 +03:00
|
|
|
if (!spapr_phb_placement(spapr, index, buid, pio, mmio32, mmio64, n_dma,
|
2023-09-18 12:17:17 +03:00
|
|
|
liobns, errp)) {
|
2020-11-21 02:42:05 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
spapr: Support NVIDIA V100 GPU with NVLink2
NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
implements special regions for such GPUs and emulates an NVLink bridge.
NVLink2-enabled POWER9 CPUs also provide address translation services
which includes an ATS shootdown (ATSD) register exported via the NVLink
bridge device.
This adds a quirk to VFIO to map the GPU memory and create an MR;
the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
this to get the MR and map it to the system address space.
Another quirk does the same for ATSD.
This adds additional steps to sPAPR PHB setup:
1. Search for specific GPUs and NPUs, collect findings in
sPAPRPHBState::nvgpus, manage system address space mappings;
2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
"memory-block", "link-speed" to advertise the NVLink2 function to
the guest;
3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
4. Add new memory blocks (with extra "linux,memory-usable" to prevent
the guest OS from accessing the new memory until it is onlined) and
npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
uses it for link discovery.
This allocates space for GPU RAM and ATSD like we do for MMIOs by
adding 2 new parameters to the phb_placement() hook. Older machine types
set these to zero.
This puts new memory nodes in a separate NUMA node to as the GPU RAM
needs to be configured equally distant from any other node in the system.
Unlike the host setup which assigns numa ids from 255 downwards, this
adds new NUMA nodes after the user configures nodes or from 1 if none
were configured.
This adds requirement similar to EEH - one IOMMU group per vPHB.
The reason for this is that ATSD registers belong to a physical NPU
so they cannot invalidate translations on GPUs attached to another NPU.
It is guaranteed by the host platform as it does not mix NVLink bridges
or GPUs from different NPU in the same IOMMU group. If more than one
IOMMU group is detected on a vPHB, this disables ATSD support for that
vPHB and prints a warning.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[aw: for vfio portions]
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <20190312082103.130561-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12 11:21:03 +03:00
|
|
|
}
|
2019-05-20 08:38:40 +03:00
|
|
|
static void spapr_machine_4_0_class_options(MachineClass *mc)
|
|
|
|
{
|
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
|
|
|
|
|
|
|
spapr_machine_4_1_class_options(mc);
|
|
|
|
compat_props_add(mc->compat_props, hw_compat_4_0, hw_compat_4_0_len);
|
|
|
|
smc->phb_placement = phb_placement_4_0;
|
2019-05-22 10:40:16 +03:00
|
|
|
smc->irq = &spapr_irq_xics;
|
2019-05-22 16:43:46 +03:00
|
|
|
smc->pre_4_1_migration = true;
|
2019-05-20 08:38:40 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_SPAPR_MACHINE(4_0, "4.0", false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pseries-3.1
|
|
|
|
*/
|
2018-07-30 17:11:31 +03:00
|
|
|
static void spapr_machine_3_1_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-12-21 03:34:48 +03:00
|
|
|
|
2018-12-04 19:27:16 +03:00
|
|
|
spapr_machine_4_0_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_3_1, hw_compat_3_1_len);
|
2019-02-18 21:13:49 +03:00
|
|
|
|
2018-12-18 01:34:44 +03:00
|
|
|
mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power8_v2.0");
|
2018-12-21 03:34:48 +03:00
|
|
|
smc->update_dt_enabled = false;
|
2019-02-19 20:18:54 +03:00
|
|
|
smc->dr_phb_enabled = false;
|
2019-03-27 05:54:11 +03:00
|
|
|
smc->broken_host_serial_model = true;
|
2019-03-01 07:46:09 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
|
2019-03-01 05:43:17 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
|
2018-07-30 17:11:31 +03:00
|
|
|
}
|
|
|
|
|
2018-12-04 19:27:16 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(3_1, "3.1", false);
|
2018-07-30 17:11:31 +03:00
|
|
|
|
2018-03-29 10:34:22 +03:00
|
|
|
/*
|
2018-05-22 13:39:59 +03:00
|
|
|
* pseries-3.0
|
2018-03-29 10:34:22 +03:00
|
|
|
*/
|
2018-07-30 17:11:31 +03:00
|
|
|
|
2018-05-22 13:39:59 +03:00
|
|
|
static void spapr_machine_3_0_class_options(MachineClass *mc)
|
2018-03-29 10:34:22 +03: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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-07-30 17:11:32 +03:00
|
|
|
|
2018-07-30 17:11:31 +03:00
|
|
|
spapr_machine_3_1_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_3_0, hw_compat_3_0_len);
|
2018-07-30 17:11:32 +03:00
|
|
|
|
|
|
|
smc->legacy_irq_allocation = true;
|
2019-09-27 06:54:23 +03:00
|
|
|
smc->nr_xirqs = 0x400;
|
2018-09-11 08:55:03 +03:00
|
|
|
smc->irq = &spapr_irq_xics_legacy;
|
2018-03-29 10:34:22 +03:00
|
|
|
}
|
|
|
|
|
2018-07-30 17:11:31 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(3_0, "3.0", false);
|
2018-03-29 10:34:22 +03:00
|
|
|
|
2017-11-13 08:50:40 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.12
|
|
|
|
*/
|
|
|
|
static void spapr_machine_2_12_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ TYPE_POWERPC_CPU, "pre-3.0-migration", "on" },
|
|
|
|
{ TYPE_SPAPR_CPU_CORE, "pre-3.0-migration", "on" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
2018-03-16 11:19:13 +03:00
|
|
|
|
2018-05-22 13:39:59 +03:00
|
|
|
spapr_machine_3_0_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_12, hw_compat_2_12_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2018-03-16 11:19:13 +03:00
|
|
|
|
2018-07-02 11:54:56 +03:00
|
|
|
/* We depend on kvm_enabled() to choose a default value for the
|
|
|
|
* hpt-max-page-size capability. Of course we can't do it here
|
2023-07-14 14:18:16 +03:00
|
|
|
* because this is too early and the HW accelerator isn't initialized
|
2018-07-02 11:54:56 +03:00
|
|
|
* yet. Postpone this to machine init (see default_caps_with_cpu()).
|
|
|
|
*/
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 0;
|
2017-11-13 08:50:40 +03:00
|
|
|
}
|
|
|
|
|
2018-03-29 10:34:22 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_12, "2.12", false);
|
2017-11-13 08:50:40 +03:00
|
|
|
|
2018-03-01 09:38:04 +03:00
|
|
|
static void spapr_machine_2_12_sxxm_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-03-01 09:38:04 +03:00
|
|
|
|
|
|
|
spapr_machine_2_12_class_options(mc);
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_WORKAROUND;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_WORKAROUND;
|
|
|
|
smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_FIXED_CCD;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_SPAPR_MACHINE(2_12_sxxm, "2.12-sxxm", false);
|
|
|
|
|
2017-07-25 21:01:12 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.11
|
|
|
|
*/
|
2017-11-13 08:50:40 +03:00
|
|
|
|
2017-07-25 21:01:12 +03:00
|
|
|
static void spapr_machine_2_11_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2017-12-11 05:10:44 +03:00
|
|
|
|
2017-11-13 08:50:40 +03:00
|
|
|
spapr_machine_2_12_class_options(mc);
|
2018-01-12 08:33:43 +03:00
|
|
|
smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_ON;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_11, hw_compat_2_11_len);
|
2017-07-25 21:01:12 +03:00
|
|
|
}
|
|
|
|
|
2017-11-13 08:50:40 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_11, "2.11", false);
|
2017-07-25 21:01:12 +03:00
|
|
|
|
2017-03-07 03:02:28 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.10
|
|
|
|
*/
|
2017-07-25 21:01:12 +03:00
|
|
|
|
2017-03-07 03:02:28 +03:00
|
|
|
static void spapr_machine_2_10_class_options(MachineClass *mc)
|
|
|
|
{
|
2017-07-25 21:01:12 +03:00
|
|
|
spapr_machine_2_11_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_10, hw_compat_2_10_len);
|
2017-03-07 03:02:28 +03:00
|
|
|
}
|
|
|
|
|
2017-07-25 21:01:12 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_10, "2.10", false);
|
2017-03-07 03:02:28 +03:00
|
|
|
|
2016-12-08 08:39:18 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.9
|
|
|
|
*/
|
2017-03-07 03:02:28 +03:00
|
|
|
|
2016-12-08 08:39:18 +03:00
|
|
|
static void spapr_machine_2_9_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ TYPE_POWERPC_CPU, "pre-2.10-migration", "on" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
2017-06-14 16:29:19 +03:00
|
|
|
|
2017-03-07 03:02:28 +03:00
|
|
|
spapr_machine_2_10_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_9, hw_compat_2_9_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2017-06-14 16:29:19 +03:00
|
|
|
smc->pre_2_10_has_unused_icps = true;
|
2017-07-12 10:53:17 +03:00
|
|
|
smc->resize_hpt_default = SPAPR_RESIZE_HPT_DISABLED;
|
2016-12-08 08:39:18 +03:00
|
|
|
}
|
|
|
|
|
2017-03-07 03:02:28 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_9, "2.9", false);
|
2016-12-08 08:39:18 +03:00
|
|
|
|
2016-09-28 07:31:55 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.8
|
|
|
|
*/
|
2016-12-08 08:39:18 +03:00
|
|
|
|
2016-09-28 07:31:55 +03:00
|
|
|
static void spapr_machine_2_8_class_options(MachineClass *mc)
|
|
|
|
{
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "pcie-extended-configuration-space", "off" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
|
|
|
|
2016-12-08 08:39:18 +03:00
|
|
|
spapr_machine_2_9_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_8, hw_compat_2_8_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2017-03-21 13:25:42 +03:00
|
|
|
mc->numa_mem_align_shift = 23;
|
2016-09-28 07:31:55 +03:00
|
|
|
}
|
|
|
|
|
2016-12-08 08:39:18 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_8, "2.8", false);
|
2016-09-28 07:31:55 +03:00
|
|
|
|
2016-06-03 08:49:42 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.7
|
|
|
|
*/
|
2016-10-16 04:04:15 +03:00
|
|
|
|
2020-11-21 02:42:05 +03:00
|
|
|
static bool phb_placement_2_7(SpaprMachineState *spapr, uint32_t index,
|
2016-10-16 04:04:15 +03:00
|
|
|
uint64_t *buid, hwaddr *pio,
|
|
|
|
hwaddr *mmio32, hwaddr *mmio64,
|
2023-09-18 12:17:17 +03:00
|
|
|
unsigned n_dma, uint32_t *liobns, Error **errp)
|
2016-10-16 04:04:15 +03:00
|
|
|
{
|
|
|
|
/* Legacy PHB placement for pseries-2.7 and earlier machine types */
|
|
|
|
const uint64_t base_buid = 0x800000020000000ULL;
|
|
|
|
const hwaddr phb_spacing = 0x1000000000ULL; /* 64 GiB */
|
|
|
|
const hwaddr mmio_offset = 0xa0000000; /* 2 GiB + 512 MiB */
|
|
|
|
const hwaddr pio_offset = 0x80000000; /* 2 GiB */
|
|
|
|
const uint32_t max_index = 255;
|
|
|
|
const hwaddr phb0_alignment = 0x10000000000ULL; /* 1 TiB */
|
|
|
|
|
|
|
|
uint64_t ram_top = MACHINE(spapr)->ram_size;
|
|
|
|
hwaddr phb0_base, phb_base;
|
|
|
|
int i;
|
|
|
|
|
2018-04-23 19:51:25 +03:00
|
|
|
/* Do we have device memory? */
|
2023-06-23 15:45:47 +03:00
|
|
|
if (MACHINE(spapr)->device_memory) {
|
2016-10-16 04:04:15 +03:00
|
|
|
/* Can't just use maxram_size, because there may be an
|
2018-04-23 19:51:25 +03:00
|
|
|
* alignment gap between normal and device memory regions
|
|
|
|
*/
|
2018-04-23 19:51:17 +03:00
|
|
|
ram_top = MACHINE(spapr)->device_memory->base +
|
|
|
|
memory_region_size(&MACHINE(spapr)->device_memory->mr);
|
2016-10-16 04:04:15 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
phb0_base = QEMU_ALIGN_UP(ram_top, phb0_alignment);
|
|
|
|
|
|
|
|
if (index > max_index) {
|
|
|
|
error_setg(errp, "\"index\" for PAPR PHB is too large (max %u)",
|
|
|
|
max_index);
|
2020-11-21 02:42:05 +03:00
|
|
|
return false;
|
2016-10-16 04:04:15 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
*buid = base_buid + index;
|
|
|
|
for (i = 0; i < n_dma; ++i) {
|
|
|
|
liobns[i] = SPAPR_PCI_LIOBN(index, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
phb_base = phb0_base + index * phb_spacing;
|
|
|
|
*pio = phb_base + pio_offset;
|
|
|
|
*mmio32 = phb_base + mmio_offset;
|
|
|
|
/*
|
|
|
|
* We don't set the 64-bit MMIO window, relying on the PHB's
|
|
|
|
* fallback behaviour of automatically splitting a large "32-bit"
|
|
|
|
* window into contiguous 32-bit and 64-bit windows
|
|
|
|
*/
|
spapr: Support NVIDIA V100 GPU with NVLink2
NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
implements special regions for such GPUs and emulates an NVLink bridge.
NVLink2-enabled POWER9 CPUs also provide address translation services
which includes an ATS shootdown (ATSD) register exported via the NVLink
bridge device.
This adds a quirk to VFIO to map the GPU memory and create an MR;
the new MR is stored in a PCI device as a QOM link. The sPAPR PCI uses
this to get the MR and map it to the system address space.
Another quirk does the same for ATSD.
This adds additional steps to sPAPR PHB setup:
1. Search for specific GPUs and NPUs, collect findings in
sPAPRPHBState::nvgpus, manage system address space mappings;
2. Add device-specific properties such as "ibm,npu", "ibm,gpu",
"memory-block", "link-speed" to advertise the NVLink2 function to
the guest;
3. Add "mmio-atsd" to vPHB to advertise the ATSD capability;
4. Add new memory blocks (with extra "linux,memory-usable" to prevent
the guest OS from accessing the new memory until it is onlined) and
npuphb# nodes representing an NPU unit for every vPHB as the GPU driver
uses it for link discovery.
This allocates space for GPU RAM and ATSD like we do for MMIOs by
adding 2 new parameters to the phb_placement() hook. Older machine types
set these to zero.
This puts new memory nodes in a separate NUMA node to as the GPU RAM
needs to be configured equally distant from any other node in the system.
Unlike the host setup which assigns numa ids from 255 downwards, this
adds new NUMA nodes after the user configures nodes or from 1 if none
were configured.
This adds requirement similar to EEH - one IOMMU group per vPHB.
The reason for this is that ATSD registers belong to a physical NPU
so they cannot invalidate translations on GPUs attached to another NPU.
It is guaranteed by the host platform as it does not mix NVLink bridges
or GPUs from different NPU in the same IOMMU group. If more than one
IOMMU group is detected on a vPHB, this disables ATSD support for that
vPHB and prints a warning.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[aw: for vfio portions]
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Message-Id: <20190312082103.130561-1-aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-03-12 11:21:03 +03:00
|
|
|
|
2020-11-21 02:42:05 +03:00
|
|
|
return true;
|
2016-10-16 04:04:15 +03:00
|
|
|
}
|
2016-09-28 07:31:55 +03:00
|
|
|
|
2016-06-03 08:49:42 +03:00
|
|
|
static void spapr_machine_2_7_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "mem_win_size", "0xf80000000", },
|
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "mem64_win_size", "0", },
|
|
|
|
{ TYPE_POWERPC_CPU, "pre-2.8-migration", "on", },
|
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "pre-2.8-migration", "on", },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
2016-10-05 10:44:51 +03:00
|
|
|
|
2016-09-28 07:31:55 +03:00
|
|
|
spapr_machine_2_8_class_options(mc);
|
2017-10-09 22:51:05 +03:00
|
|
|
mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power7_v2.3");
|
2018-12-05 23:58:24 +03:00
|
|
|
mc->default_machine_opts = "modern-hotplug-events=off";
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_7, hw_compat_2_7_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2016-10-16 04:04:15 +03:00
|
|
|
smc->phb_placement = phb_placement_2_7;
|
2016-06-03 08:49:42 +03:00
|
|
|
}
|
|
|
|
|
2016-09-28 07:31:55 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_7, "2.7", false);
|
2016-06-03 08:49:42 +03:00
|
|
|
|
2015-12-07 06:28:15 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.6
|
|
|
|
*/
|
2016-06-03 08:49:42 +03:00
|
|
|
|
2015-12-07 06:28:15 +03:00
|
|
|
static void spapr_machine_2_6_class_options(MachineClass *mc)
|
|
|
|
{
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "ddw", "off" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
|
|
|
|
2016-06-03 08:49:42 +03:00
|
|
|
spapr_machine_2_7_class_options(mc);
|
2017-02-10 13:20:57 +03:00
|
|
|
mc->has_hotpluggable_cpus = false;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_6, hw_compat_2_6_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2015-12-07 06:28:15 +03:00
|
|
|
}
|
|
|
|
|
2016-06-03 08:49:42 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_6, "2.6", false);
|
2015-12-07 06:28:15 +03:00
|
|
|
|
2015-12-03 09:34:10 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.5
|
|
|
|
*/
|
2015-12-07 06:28:15 +03:00
|
|
|
|
2015-12-07 06:23:20 +03:00
|
|
|
static void spapr_machine_2_5_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ "spapr-vlan", "use-rx-buffer-pools", "off" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
2015-12-09 15:34:13 +03:00
|
|
|
|
2015-12-07 06:28:15 +03:00
|
|
|
spapr_machine_2_6_class_options(mc);
|
2015-12-09 15:34:13 +03:00
|
|
|
smc->use_ohci_by_default = true;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_5, hw_compat_2_5_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2015-12-03 09:34:10 +03:00
|
|
|
}
|
|
|
|
|
2015-12-07 06:28:15 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_5, "2.5", false);
|
2015-12-03 09:34:10 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pseries-2.4
|
|
|
|
*/
|
2015-10-16 13:25:53 +03:00
|
|
|
|
2015-12-07 06:23:20 +03:00
|
|
|
static void spapr_machine_2_4_class_options(MachineClass *mc)
|
|
|
|
{
|
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 07:35:37 +03:00
|
|
|
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
|
2015-12-07 06:27:21 +03:00
|
|
|
|
|
|
|
spapr_machine_2_5_class_options(mc);
|
|
|
|
smc->dr_lmb_enabled = false;
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_4, hw_compat_2_4_len);
|
2015-12-03 09:34:10 +03:00
|
|
|
}
|
|
|
|
|
2015-12-07 06:25:50 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_4, "2.4", false);
|
2015-12-03 09:34:10 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pseries-2.3
|
|
|
|
*/
|
2015-05-14 21:53:05 +03:00
|
|
|
|
2015-12-07 06:23:20 +03:00
|
|
|
static void spapr_machine_2_3_class_options(MachineClass *mc)
|
2014-06-25 08:08:45 +04:00
|
|
|
{
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ "spapr-pci-host-bridge", "dynamic-reconfiguration", "off" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
2015-12-07 06:27:21 +03:00
|
|
|
spapr_machine_2_4_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_3, hw_compat_2_3_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2014-06-25 08:08:45 +04:00
|
|
|
}
|
2015-12-07 06:25:50 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_3, "2.3", false);
|
2014-06-25 08:08:45 +04:00
|
|
|
|
2015-12-03 09:34:10 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.2
|
|
|
|
*/
|
|
|
|
|
2015-12-07 06:23:20 +03:00
|
|
|
static void spapr_machine_2_2_class_options(MachineClass *mc)
|
2014-09-08 09:30:31 +04:00
|
|
|
{
|
2018-12-12 17:01:23 +03:00
|
|
|
static GlobalProperty compat[] = {
|
2019-01-07 22:30:20 +03:00
|
|
|
{ TYPE_SPAPR_PCI_HOST_BRIDGE, "mem_win_size", "0x20000000" },
|
2018-12-12 17:01:23 +03:00
|
|
|
};
|
|
|
|
|
2015-12-07 06:27:21 +03:00
|
|
|
spapr_machine_2_3_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_2, hw_compat_2_2_len);
|
2018-12-12 17:01:23 +03:00
|
|
|
compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
|
2018-12-05 23:58:25 +03:00
|
|
|
mc->default_machine_opts = "modern-hotplug-events=off,suppress-vmdesc=on";
|
2014-09-08 09:30:31 +04:00
|
|
|
}
|
2015-12-07 06:25:50 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_2, "2.2", false);
|
2014-09-08 09:30:31 +04:00
|
|
|
|
2015-12-03 09:34:10 +03:00
|
|
|
/*
|
|
|
|
* pseries-2.1
|
|
|
|
*/
|
2015-01-30 04:53:18 +03:00
|
|
|
|
2015-12-07 06:23:20 +03:00
|
|
|
static void spapr_machine_2_1_class_options(MachineClass *mc)
|
2015-04-23 09:21:37 +03:00
|
|
|
{
|
2015-12-07 06:27:21 +03:00
|
|
|
spapr_machine_2_2_class_options(mc);
|
2018-12-12 18:36:30 +03:00
|
|
|
compat_props_add(mc->compat_props, hw_compat_2_1, hw_compat_2_1_len);
|
2015-04-23 09:21:37 +03:00
|
|
|
}
|
2015-12-07 06:25:50 +03:00
|
|
|
DEFINE_SPAPR_MACHINE(2_1, "2.1", false);
|
2015-08-12 06:15:56 +03:00
|
|
|
|
2014-03-17 06:40:26 +04:00
|
|
|
static void spapr_machine_register_types(void)
|
2011-04-01 08:15:20 +04:00
|
|
|
{
|
2014-03-17 06:40:26 +04:00
|
|
|
type_register_static(&spapr_machine_info);
|
2011-04-01 08:15:20 +04:00
|
|
|
}
|
|
|
|
|
2014-03-17 06:40:26 +04:00
|
|
|
type_init(spapr_machine_register_types)
|