2013-02-05 15:03:15 +04:00
|
|
|
# shared objects
|
2019-12-31 21:32:13 +03:00
|
|
|
obj-y += ppc.o ppc_booke.o
|
|
|
|
obj-$(CONFIG_FDT_PPC) += fdt.o
|
2019-12-31 21:32:12 +03:00
|
|
|
obj-$(CONFIG_FW_CFG_PPC) += fw_cfg.o
|
2013-02-05 15:03:15 +04:00
|
|
|
# IBM pSeries (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
|
|
|
obj-$(CONFIG_PSERIES) += spapr.o spapr_caps.o spapr_vio.o spapr_events.o
|
2013-02-05 15:20:00 +04:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
|
2018-10-08 15:39:42 +03:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
|
2018-07-30 17:11:32 +03:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o spapr_irq.o
|
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
|
|
|
obj-$(CONFIG_PSERIES) += spapr_tpm_proxy.o spapr_nvdimm.o
|
2018-10-08 15:39:42 +03:00
|
|
|
obj-$(CONFIG_SPAPR_RNG) += spapr_rng.o
|
2019-12-31 21:32:11 +03:00
|
|
|
obj-$(call land,$(CONFIG_PSERIES),$(CONFIG_LINUX)) += spapr_pci_vfio.o spapr_pci_nvlink2.o
|
2016-10-22 12:46:35 +03:00
|
|
|
# IBM PowerNV
|
2017-04-11 18:30:05 +03:00
|
|
|
obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o pnv_occ.o pnv_bmc.o
|
2019-10-21 16:12:11 +03:00
|
|
|
obj-$(CONFIG_POWERNV) += pnv_homer.o pnv_pnor.o
|
|
|
|
|
2016-07-04 06:33:07 +03:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_rtas_ddw.o
|
2013-02-05 15:03:15 +04:00
|
|
|
# PowerPC 4xx boards
|
2019-02-02 10:24:40 +03:00
|
|
|
obj-$(CONFIG_PPC405) += ppc405_boards.o ppc405_uc.o
|
|
|
|
obj-$(CONFIG_PPC440) += ppc440_bamboo.o ppc440_pcix.o ppc440_uc.o
|
|
|
|
obj-$(CONFIG_PPC4XX) += ppc4xx_pci.o ppc4xx_devs.o
|
2018-07-02 04:59:35 +03:00
|
|
|
obj-$(CONFIG_SAM460EX) += sam460ex.o
|
2013-01-26 23:41:58 +04:00
|
|
|
# PReP
|
2014-01-23 14:22:16 +04:00
|
|
|
obj-$(CONFIG_PREP) += prep.o
|
2017-01-07 18:23:41 +03:00
|
|
|
obj-$(CONFIG_PREP) += prep_systemio.o
|
2017-01-07 18:23:42 +03:00
|
|
|
obj-${CONFIG_RS6000_MC} += rs6000_mc.o
|
2013-01-24 03:03:54 +04:00
|
|
|
# OldWorld PowerMac
|
2019-02-02 10:24:40 +03:00
|
|
|
obj-$(CONFIG_MAC_OLDWORLD) += mac_oldworld.o
|
2013-01-24 03:03:54 +04:00
|
|
|
# NewWorld PowerMac
|
2019-02-02 10:24:40 +03:00
|
|
|
obj-$(CONFIG_MAC_NEWWORLD) += mac_newworld.o
|
2013-01-24 03:03:54 +04:00
|
|
|
# e500
|
2013-02-05 15:52:23 +04:00
|
|
|
obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
|
2013-02-05 18:22:56 +04:00
|
|
|
obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
|
2013-02-05 15:03:15 +04:00
|
|
|
# PowerPC 440 Xilinx ML507 reference board.
|
2019-02-02 10:24:40 +03:00
|
|
|
obj-$(CONFIG_VIRTEX) += virtex_ml507.o
|