aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc/e500.h
AgeCommit message (Collapse)Author
2015-01-07PPC: e500 pci host: Add support for ATMUsAlexander Graf
The e500 PCI controller has configurable windows that allow a guest OS to selectively map parts of the PCI bus space to CPU address space and to selectively map parts of the CPU address space for DMA requests into PCI visible address ranges. So far, we've simply assumed that this mapping is 1:1 and ignored it. However, the PCICSRBAR (CCSR mapped in PCI bus space) always has to live inside the first 32bits of address space. This means if we always treat all mappings as 1:1, this map will collide with our RAM map from the CPU's point of view. So this patch adds proper ATMU support which allows us to keep the PCICSRBAR below 32bits local to the PCI bus and have another, different window to PCI BARs at the upper end of address space. We leverage this on e500plat though, mpc8544ds stays virtually 1:1 like it was before, but now also goes via ATMU. With this patch, I can run guests with lots of RAM and not coincidently access MSI-X mappings while I really want to access RAM. Signed-off-by: Alexander Graf <agraf@suse.de>
2015-01-07PPC: e500: Move CCSR definition to paramsAlexander Graf
We want to have different MMIO region offsets for the mpc8544ds machine and our e500 PV machine, so move the definitions of those into the machine specific params struct. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-04PPC: e500: Support dynamically spawned sysbus devicesAlexander Graf
For e500 our approach to supporting dynamically spawned sysbus devices is to create a simple bus from the guest's point of view within which we map those devices dynamically. We allocate memory regions always within the "platform" hole in address space and map IRQs to predetermined IRQ lines that are reserved for platform device usage. This maps really nicely into device tree logic, so we can just tell the guest about our virtual simple bus in device tree as well. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-04PPC: E500: Instantiate MPC8XXX gpio controller on virt machineAlexander Graf
With the e500 virt machine, we don't have to adhere to the exact hardware layout of an mpc8544ds board. So there we can just add a qoriq compatible GPIO controller into the system that we can add a power off hook to. Signed-off-by: Alexander Graf <agraf@suse.de>
2014-05-28machine: Conversion of QEMUMachineInitArgs to MachineStateMarcel Apfelbaum
Total removal of QEMUMachineInitArgs struct. QEMUMachineInitArgs's fields are copied into MachineState. Removed duplicated fields from MachineState. All the other changes are only mechanical refactoring, no semantic changes. Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> (s390) Reviewed-by: Michael S. Tsirkin <mst@redhat.com> (PC) [AF: Renamed ms -> machine, use MACHINE_GET_CLASS()] Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-08-21ppc: Don't duplicate QEMUMachineInitArgs in PPCE500ParamsMarkus Armbruster
Pass on the generic arguments unadulterated, and the machine-specific ones as separate argument. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Alexander Graf <agraf@suse.de> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-01-25PPC: e500: Select MPIC v4.2 on ppce500 platformScott Wood
The compatible string is changed to fsl,mpic on all e500 platforms, to advertise the existence of BRR1. This matches what the device tree will have on real hardware. With MPIC v4.2 max_cpu can be increased from 15 to 32. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2012-12-14PPC: E500: Move PCI slot information into paramsAlexander Graf
We have a params struct that allows us to expose differences between e500 machine models. Include PCI slot information there, so we can have different machines with different PCI slot topology. Signed-off-by: Alexander Graf <agraf@suse.de>
2012-08-15PPC: e500: split mpc8544ds machine from generic e500 codeScott Wood
Currently the only mpc8544ds-ism that is factored out is toplevel compatible and model. In the future the generic e500 code is expected to become more generic. Signed-off-by: Scott Wood <scottwood@freescale.com> [agraf: conditionalize on CONFIG_FDT] Signed-off-by: Alexander Graf <agraf@suse.de>