2013-02-05 12:03:15 +01:00
|
|
|
# shared objects
|
2016-08-02 19:38:01 +02:00
|
|
|
obj-y += ppc.o ppc_booke.o fdt.o
|
2013-02-05 12:03:15 +01:00
|
|
|
# IBM pSeries (sPAPR)
|
2013-07-06 15:53:58 +02:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
|
2013-02-05 12:20:00 +01:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
|
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 10:49:41 +02:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
|
2016-06-10 02:59:01 +02:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
|
2016-10-22 11:46:35 +02:00
|
|
|
# IBM PowerNV
|
ppc/pnv: add XSCOM infrastructure
On a real POWER8 system, the Pervasive Interconnect Bus (PIB) serves
as a backbone to connect different units of the system. The host
firmware connects to the PIB through a bridge unit, the
Alter-Display-Unit (ADU), which gives him access to all the chiplets
on the PCB network (Pervasive Connect Bus), the PIB acting as the root
of this network.
XSCOM (serial communication) is the interface to the sideband bus
provided by the POWER8 pervasive unit to read and write to chiplets
resources. This is needed by the host firmware, OPAL and to a lesser
extent, Linux. This is among others how the PCI Host bridges get
configured at boot or how the LPC bus is accessed.
To represent the ADU of a real system, we introduce a specific
AddressSpace to dispatch XSCOM accesses to the targeted chiplets. The
translation of an XSCOM address into a PCB register address is
slightly different between the P9 and the P8. This is handled before
the dispatch using a 8byte alignment for all.
To customize the device tree, a QOM InterfaceClass, PnvXScomInterface,
is provided with a populate() handler. The chip populates the device
tree by simply looping on its children. Therefore, each model needing
custom nodes should not forget to declare itself as a child at
instantiation time.
Based on previous work done by :
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[dwg: Added cpu parameter to xscom_complete()]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-22 11:46:40 +02:00
|
|
|
obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o
|
spapr_pci_vfio: Add spapr-pci-vfio-host-bridge to support vfio
The patch adds a spapr-pci-vfio-host-bridge device type
which is a PCI Host Bridge with VFIO support. The new device
inherits from the spapr-pci-host-bridge device and adds an "iommu"
property which is an IOMMU id. This ID represents a minimal entity
for which IOMMU isolation can be guaranteed. In SPAPR architecture IOMMU
group is called a Partitionable Endpoint (PE).
Current implementation supports one IOMMU id per QEMU VFIO PHB. Since
SPAPR allows multiple PHB for no extra cost, this does not seem to
be a problem. This limitation may change in the future though.
Example of use:
Configure and Add 3 functions of a multifunctional device to QEMU:
(the NEC PCI USB card is used as an example here):
-device spapr-pci-vfio-host-bridge,id=USB,iommu=4,index=7 \
-device vfio-pci,host=4:0:1.0,addr=1.0,bus=USB,multifunction=true
-device vfio-pci,host=4:0:1.1,addr=1.1,bus=USB
-device vfio-pci,host=4:0:1.2,addr=1.2,bus=USB
where:
* index=7 is a QEMU PHB index (used as source for MMIO/MSI/IO windows
offset);
* iommu=4 is an IOMMU id which can be found in sysfs:
[aik@vpl2 ~]$ cd /sys/bus/pci/devices/0004:00:00.0/
[aik@vpl2 0004:00:00.0]$ ls -l iommu_group
lrwxrwxrwx 1 root root 0 Jun 5 12:49 iommu_group -> ../../../kernel/iommu_groups/4
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-06-10 07:39:23 +02:00
|
|
|
ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
|
|
|
|
|
obj-y += spapr_pci_vfio.o
|
|
|
|
|
endif
|
2016-07-04 05:33:07 +02:00
|
|
|
obj-$(CONFIG_PSERIES) += spapr_rtas_ddw.o
|
2013-02-05 12:03:15 +01:00
|
|
|
# PowerPC 4xx boards
|
2013-02-05 15:22:56 +01:00
|
|
|
obj-y += ppc405_boards.o ppc4xx_devs.o ppc405_uc.o ppc440_bamboo.o
|
2013-02-05 15:06:20 +01:00
|
|
|
obj-y += ppc4xx_pci.o
|
2013-01-26 20:41:58 +01:00
|
|
|
# PReP
|
2014-01-23 11:22:16 +01:00
|
|
|
obj-$(CONFIG_PREP) += prep.o
|
2013-01-24 00:03:54 +01:00
|
|
|
# OldWorld PowerMac
|
2014-01-23 16:37:55 +01:00
|
|
|
obj-$(CONFIG_MAC) += mac_oldworld.o
|
2013-01-24 00:03:54 +01:00
|
|
|
# NewWorld PowerMac
|
2014-01-23 16:37:55 +01:00
|
|
|
obj-$(CONFIG_MAC) += mac_newworld.o
|
2013-01-24 00:03:54 +01:00
|
|
|
# e500
|
2013-02-05 12:52:23 +01:00
|
|
|
obj-$(CONFIG_E500) += e500.o mpc8544ds.o e500plat.o
|
2013-02-05 15:22:56 +01:00
|
|
|
obj-$(CONFIG_E500) += mpc8544_guts.o ppce500_spin.o
|
2013-02-05 12:03:15 +01:00
|
|
|
# PowerPC 440 Xilinx ML507 reference board.
|
2014-08-26 06:30:18 +02:00
|
|
|
obj-$(CONFIG_XILINX) += virtex_ml507.o
|
