summaryrefslogtreecommitdiffstats
path: root/hw/ppc/pnv.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'patchew/20200219160953.13771-1-imammedo@redhat.com' of ↵Paolo Bonzini2020-02-251-6/+2Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://github.com/patchew-project/qemu into HEAD This series removes ad hoc RAM allocation API (memory_region_allocate_system_memory) and consolidates it around hostmem backend. It allows to * resolve conflicts between global -mem-prealloc and hostmem's "policy" option, fixing premature allocation before binding policy is applied * simplify complicated memory allocation routines which had to deal with 2 ways to allocate RAM. * reuse hostmem backends of a choice for main RAM without adding extra CLI options to duplicate hostmem features. A recent case was -mem-shared, to enable vhost-user on targets that don't support hostmem backends [1] (ex: s390) * move RAM allocation from individual boards into generic machine code and provide them with prepared MemoryRegion. * clean up deprecated NUMA features which were tied to the old API (see patches) - "numa: remove deprecated -mem-path fallback to anonymous RAM" - (POSTPONED, waiting on libvirt side) "forbid '-numa node,mem' for 5.0 and newer machine types" - (POSTPONED) "numa: remove deprecated implicit RAM distribution between nodes" Introduce a new machine.memory-backend property and wrapper code that aliases global -mem-path and -mem-alloc into automatically created hostmem backend properties (provided memory-backend was not set explicitly given by user). A bulk of trivial patches then follow to incrementally convert individual boards to using machine.memory-backend provided MemoryRegion. Board conversion typically involves: * providing MachineClass::default_ram_size and MachineClass::default_ram_id so generic code could create default backend if user didn't explicitly provide memory-backend or -m options * dropping memory_region_allocate_system_memory() call * using convenience MachineState::ram MemoryRegion, which points to MemoryRegion allocated by ram-memdev On top of that for some boards: * missing ram_size checks are added (typically it were boards with fixed ram size) * ram_size fixups are replaced by checks and hard errors, forcing user to provide correct "-m" values instead of ignoring it and continuing running. After all boards are converted, the old API is removed and memory allocation routines are cleaned up.
| * ppc/pnv: use memdev for RAMIgor Mammedov2020-02-191-6/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | memory_region_allocate_system_memory() API is going away, so replace it with memdev allocated MemoryRegion. The later is initialized by generic code, so board only needs to opt in to memdev scheme by providing MachineClass::default_ram_id and using MachineState::ram instead of manually initializing RAM memory region. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200219160953.13771-63-imammedo@redhat.com>
* | ppc: free 'fdt' after reset the machinePan Nengyuan2020-02-201-0/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'fdt' forgot to clean both e500 and pnv when we call 'system_reset' on ppc, this patch fix it. The leak stacks are as follow: Direct leak of 4194304 byte(s) in 4 object(s) allocated from: #0 0x7fafe37dd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7fafe2e3149d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x561876f7f80d in create_device_tree /mnt/sdb/qemu-new/qemu/device_tree.c:40 #3 0x561876b7ac29 in ppce500_load_device_tree /mnt/sdb/qemu-new/qemu/hw/ppc/e500.c:364 #4 0x561876b7f437 in ppce500_reset_device_tree /mnt/sdb/qemu-new/qemu/hw/ppc/e500.c:617 #5 0x56187718b1ae in qemu_devices_reset /mnt/sdb/qemu-new/qemu/hw/core/reset.c:69 #6 0x561876f6938d in qemu_system_reset /mnt/sdb/qemu-new/qemu/vl.c:1412 #7 0x561876f6a25b in main_loop_should_exit /mnt/sdb/qemu-new/qemu/vl.c:1645 #8 0x561876f6a398 in main_loop /mnt/sdb/qemu-new/qemu/vl.c:1679 #9 0x561876f7da8e in main /mnt/sdb/qemu-new/qemu/vl.c:4438 #10 0x7fafde16b812 in __libc_start_main ../csu/libc-start.c:308 #11 0x5618765c055d in _start (/mnt/sdb/qemu-new/qemu/build/ppc64-softmmu/qemu-system-ppc64+0x2b1555d) Direct leak of 1048576 byte(s) in 1 object(s) allocated from: #0 0x7fc0a6f1b970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7fc0a656f49d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x55eb05acd2ca in pnv_dt_create /mnt/sdb/qemu-new/qemu/hw/ppc/pnv.c:507 #3 0x55eb05ace5bf in pnv_reset /mnt/sdb/qemu-new/qemu/hw/ppc/pnv.c:578 #4 0x55eb05f2f395 in qemu_system_reset /mnt/sdb/qemu-new/qemu/vl.c:1410 #5 0x55eb05f43850 in main /mnt/sdb/qemu-new/qemu/vl.c:4403 #6 0x7fc0a18a9812 in __libc_start_main ../csu/libc-start.c:308 #7 0x55eb0558655d in _start (/mnt/sdb/qemu-new/qemu/build/ppc64-softmmu/qemu-system-ppc64+0x2b1555d) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200214033206.4395-1-pannengyuan@huawei.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridgeCédric Le Goater2020-02-021-2/+67
| | | | | | | | | | | | | | | | | | | | | | | This is a model of the PCIe Host Bridge (PHB3) found on a POWER8 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.3 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER8 system using the XICS interrupt controller. The POWER8 processor comes in different flavors: Venice, Murano, Naple, each having a different number of PHBs. To make things simpler, the models provides 3 PHB3 per chip. Some platforms, like the Firestone, can also couple PHBs on the first chip to provide more bandwidth but this is too specific to model in QEMU. XICS requires some adjustment to support the PHB3 MSI. The changes are provided here but they could be decoupled in prereq patches. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-3-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridgeBenjamin Herrenschmidt2020-02-021-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These changes introduces models for the PCIe Host Bridge (PHB4) of the POWER9 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.4 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER9 system using the XIVE interrupt controller. POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs. By default, * PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5) Each PEC has a set "global" registers and some "per-stack" (per-PHB) registers. Those are organized in two XSCOM ranges, the "Nest" range and the "PCI" range, each range contains both some "PEC" registers and some "per-stack" registers. No default device layout is provided and PCI devices can be added on any of the available PCIe Root Port (pcie.0 .. 2 of a Power9 chip) with address 0x0 as the firwware (skiboot) only accepts a single device per root port. To run a simple system with a network and a storage adapters, use a command line options such as : -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0 -netdev bridge,id=net0,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=hostnet0 -device megasas,id=scsi0,bus=pcie.1,addr=0x0 -drive file=$disk,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 If more are needed, include a bridge. Multi chip is supported, each chip adding its set of PHB4 controllers and its PCI busses. The model doesn't emulate the EEH error handling. This model is not ready for hotplug yet. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [ clg: - numerous cleanups - commit log - fix for broken LSI support - PHB pic printinfo - large QOM rework ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-2-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add support for "hostboot" modeCédric Le Goater2020-02-021-1/+27
| | | | | | | | | | | | | When the "hb-mode" option is activated on the powernv machine, the firmware is mapped at 0x8000000 and the HRMOR of the HW threads are set to the same address. The PNOR mapping on the FW address space of the LPC bus is left enabled to let the firmware load any other images required to boot the host. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144154.10170-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* qdev: set properties with device_class_set_props()Marc-André Lureau2020-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* pnv/xive: Deduce the PnvXive pointer from XiveTCTX::xptrGreg Kurz2020-01-081-14/+0Star
| | | | | | | | | | And use it instead of reaching out to the machine. This allows to get rid of pnv_get_chip(). Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-11-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* xive: Add a "presenter" link property to the TCTX objectCédric Le Goater2020-01-081-1/+2
| | | | | | | | | | | | | This will be used in subsequent patches to access the XIVE associated to a TCTX without reaching out to the machine through qdev_get_machine(). Signed-off-by: Cédric Le Goater <clg@kaod.org> [ groug: - split patch - write subject and changelog ] Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-9-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add a "pnor" const link property to the BMC internal simulatorGreg Kurz2020-01-081-1/+1
| | | | | | | | | This allows to get rid of a call to qdev_get_machine(). Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-8-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add an "nr-threads" property to the base chip classGreg Kurz2020-01-081-3/+5
| | | | | | | | | | | Set it at chip creation and forward it to the cores. This allows to drop a call to qdev_get_machine(). Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200106145645.4539-7-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* spapr, pnv, xive: Add a "xive-fabric" link to the XIVE routerGreg Kurz2020-01-081-0/+6
| | | | | | | | | | | | | | | In order to get rid of qdev_get_machine(), first add a pointer to the XIVE fabric under the XIVE router and make it configurable through a QOM link property. Configure it in the spapr and pnv machine. In the case of pnv, the XIVE routers are under the chip, so this is done with a QOM alias property of the POWER9 pnv chip. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200106145645.4539-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce a "xics" property under the POWER8 chipCédric Le Goater2020-01-081-5/+19
| | | | | | | | | | | | POWER8 is the only chip using the XICS interface. Add a "xics" link and a XICSFabric attribute under this chip to remove the use of qdev_get_machine() Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200106145645.4539-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce a "xics" property alias under the PSI modelCédric Le Goater2020-01-081-2/+2
| | | | | | | | | | This removes the need of the intermediate link under PSI to pass the XICS link to the underlying ICSState object. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20200106145645.4539-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Drop "num-chips" machine propertyGreg Kurz2020-01-081-50/+12Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The number of CPU chips of the powernv machine is configurable through a "num-chips" property. This doesn't fit well with the CPU topology, eg. some configurations can come up with more CPUs than the maximum of CPUs set in the toplogy. This causes assertion to be hit with mttcg: -machine powernv,num-chips=2 -smp cores=2 -accel tcg,thread=multi ERROR: tcg/tcg.c:789:tcg_register_thread: assertion failed: (n < ms->smp.max_cpus) Aborted (core dumped) Mttcg mandates the CPU topology to be dimensioned to the actual number of CPUs, depending on the number of chips the user asked for. That is, '-machine num-chips=N' should always have a '-smp' companion with a topology that meats the resulting number of CPUs, typically '-smp sockets=N'. It thus seems that "num-chips" doesn't bring anything but forcing the user to specify the requested number of chips on the command line twice. Simplify the command line by computing the number of chips based on the CPU topology exclusively. The powernv machine isn't a production thing ; it is mostly used by developpers to prepare the bringup of real HW. Because of this and for simplicity, this deliberately ignores the official deprecation process and dumps "num-chips" right away : '-smp sockets=N' is now the only way to control the number of CPU chips. This is done at machine init because smp_parse() is called after instance init. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157830658266.533764.2214183961444213947.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Modify the powerdown notifier to get the PowerNV machineCédric Le Goater2020-01-081-1/+1
| | | | | | | | | | Use container_of() instead of qdev_get_machine() Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191219181155.32530-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Drop PnvChipClass::typeGreg Kurz2019-12-171-5/+0Star
| | | | | | | | | It isn't used anymore. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623844102.360005.12070225703151669294.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce PnvChipClass::xscom_pcba() methodGreg Kurz2019-12-171-0/+23
| | | | | | | | | | | | | | | | | | The XSCOM bus is implemented with a QOM interface, which is mostly generic from a CPU type standpoint, except for the computation of addresses on the Pervasive Connect Bus (PCB) network. This is handled by the pnv_xscom_pcba() function with a switch statement based on the chip_type class level attribute of the CPU chip. This can be achieved using QOM. Also the address argument is masked with PNV_XSCOM_SIZE - 1, which is for POWER8 only. Addresses may have different sizes with other CPU types. Have each CPU chip type handle the appropriate computation with a QOM xscom_pcba() method. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623843543.360005.13996472463887521794.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Pass content of the "compatible" property to pnv_dt_xscom()Greg Kurz2019-12-171-3/+9
| | | | | | | | | | | | Since pnv_dt_xscom() is called from chip specific dt_populate() hooks, it shouldn't have to guess the chip type in order to populate the "compatible" property. Just pass the compat string and its size as arguments. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623842430.360005.9513965612524265862.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Pass XSCOM base address and address size to pnv_dt_xscom()Greg Kurz2019-12-171-3/+9
| | | | | | | | | | | Since pnv_dt_xscom() is called from chip specific dt_populate() hooks, it shouldn't have to guess the chip type in order to populate the "reg" property. Just pass the base address and address size as arguments. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623841868.360005.17577624823547136435.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce PnvChipClass::xscom_core_base() methodGreg Kurz2019-12-171-7/+24
| | | | | | | | | | | | | The pnv_chip_core_realize() function configures the XSCOM MMIO subregion for each core of a single chip. The base address of the subregion depends on the CPU type. Its computation is currently open-code using the pnv_chip_is_powerXX() helpers. This can be achieved with QOM. Introduce a method for this in the base chip class and implement it in child classes. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623841311.360005.4705705734873339545.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce PnvChipClass::intc_print_info() methodGreg Kurz2019-12-171-5/+25
| | | | | | | | | | | | | | | The pnv_pic_print_info() callback checks the type of the chip in order to forward to the request appropriate interrupt controller. This can be achieved with QOM. Introduce a method for this in the base chip class and implement it in child classes. This also prepares ground for the upcoming interrupt controller of POWER10 chips. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623840755.360005.5002022339473369934.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce PnvMachineClass::dt_power_mgt()Greg Kurz2019-12-171-4/+6
| | | | | | | | | | | | | | | We add an extra node to advertise power management on some machines, namely powernv9 and powernv10. This is achieved by using the pnv_is_power9() and pnv_is_power10() helpers. This can be achieved with QOM. Add a method to the base class for powernv machines and have it implemented by machine types that support power management instead. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623839642.360005.9243510140436689941.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce PnvMachineClass and PnvMachineClass::compatGreg Kurz2019-12-171-14/+18
| | | | | | | | | | | | | | | | | The pnv_dt_create() function generates different contents for the "compatible" property of the root node in the DT, depending on the CPU type. This is open coded with multiple ifs using pnv_is_powerXX() helpers. It seems cleaner to achieve with QOM. Introduce a base class for the powernv machine and a compat attribute that each child class can use to provide the value for the "compatible" property. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157623839085.360005.4046508784077843216.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> [dwg: Folded in small fix Greg spotted after posting] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Fix OCC common area region mappingCédric Le Goater2019-12-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The OCC common area is mapped at a unique address on the system and each OCC is assigned a segment to expose its sensor data : ------------------------------------------------------------------------- | Start (Offset from | End | Size |Description | | BAR2 base address) | | | | ------------------------------------------------------------------------- | 0x00580000 | 0x005A57FF |150kB |OCC 0 Sensor Data Block| | 0x005A5800 | 0x005CAFFF |150kB |OCC 1 Sensor Data Block| | : | : | : | : | | 0x00686800 | 0x006ABFFF |150kB |OCC 7 Sensor Data Block| | 0x006AC000 | 0x006FFFFF |336kB |Reserved | ------------------------------------------------------------------------- Maximum size is 1.5MB. We could define a "OCC common area" memory region at the machine level and sub regions for each OCC. But it adds some extra complexity to the models. Fix the current layout with a simpler model. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191211082912.2625-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce PBA registersCédric Le Goater2019-12-171-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The PBA bridge unit (Power Bus Access) connects the OCC (On Chip Controller) to the Power bus and System Memory. The PBA is used to gather sensor data, for power management, for sleep states, for initial boot, among other things. The PBA logic provides a set of four registers PowerBus Access Base Address Registers (PBABAR0..3) which map the OCC address space to the PowerBus space. These registers are setup by the initial FW and define the PowerBus Range of system memory that can be accessed by PBA. The current modeling of the PBABAR registers is done under the common XSCOM handlers. We introduce a specific XSCOM regions for these registers and fix : - BAR sizes and BAR masks - The mapping of the OCC common area. It is common to all chips and should be mapped once. We will address per-OCC area in the next change. - OCC common area is in BAR 3 on P8 Inspired by previous work of Balamuruhan S <bala24@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191211082912.2625-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: add a LPC Controller model for POWER10Cédric Le Goater2019-12-171-3/+22
| | | | | | | | Same a POWER9, only the MMIO window changes. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191205184454.10722-6-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: add a PSI bridge model for POWER10Cédric Le Goater2019-12-171-7/+20
| | | | | | | | | | | The POWER10 PSIHB controller is very similar to the one on POWER9. We should probably introduce a common PnvPsiXive object. The ESB page size should be changed to 64k when P10 support is ready. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191205184454.10722-5-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Introduce a POWER10 PnvChip and a powernv10 machineCédric Le Goater2019-12-171-6/+152
| | | | | | | | | This is an empty shell with the XSCOM bus and cores. The chip controllers will come later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191205184454.10722-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Clarify how the TIMA is accessed on a multichip systemCédric Le Goater2019-12-171-0/+14
| | | | | | | | | | | | | | | | | | The TIMA region gives access to the thread interrupt context registers of a CPU. It is mapped at the same address on all chips and can be accessed by any CPU of the system. To identify the chip from which the access is being done, the PowerBUS uses a 'chip' field in the load/store messages. QEMU does not model these messages, instead, we extract the chip id from the CPU PIR and do a lookup at the machine level to fetch the targeted interrupt controller. Introduce pnv_get_chip() and pnv_xive_tm_get_xive() helpers to clarify this process in pnv_xive_get_tctx(). The latter will be removed in the subsequent patches but the same principle will be kept. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-14-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Implement the XiveFabric interfaceCédric Le Goater2019-12-171-0/+35
| | | | | | | | | | | The CAM line matching on the PowerNV machine now scans all chips of the system and all CPUs of a chip to find a dispatched NVT in the thread contexts. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-10-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Fix TIMA indirect accessCédric Le Goater2019-12-171-0/+17
| | | | | | | | | | | | | | When the TIMA of a CPU needs to be accessed from the indirect page, the thread id of the target CPU is first stored in the PC_TCTXT_INDIR0 register. This thread id is relative to the chip and not to the system. Introduce a helper routine to look for a CPU of a given PIR and fix pnv_xive_get_indirect_tctx() to scan only the threads of the local chip and not the whole machine. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-8-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Instantiate cores separatelyGreg Kurz2019-12-171-18/+12Star
| | | | | | | | | | | | | | | | Allocating a big void * array to store multiple objects isn't a recommended practice for various reasons: - no compile time type checking - potential dangling pointers if a reference on an individual is taken and the array is freed later on - duplicate boiler plate everywhere the array is browsed through Allocate an array of pointers and populate it instead. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191125065820.927-4-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Create BMC devices at machine initCédric Le Goater2019-12-171-17/+16Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BMC of the OpenPOWER systems monitors the machine state using sensors, controls the power and controls the access to the PNOR flash device containing the firmware image required to boot the host. QEMU models the power cycle process, access to the sensors and access to the PNOR device. But, for these features to be available, the QEMU PowerNV machine needs two extras devices on the command line, an IPMI BT device for communication and a BMC backend device: -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10 The BMC properties are then defined accordingly in the device tree and OPAL self adapts. If a BMC device and an IPMI BT device are not available, OPAL does not try to communicate with the BMC in any manner. This is not how real systems behave. To be closer to the default behavior, create an IPMI BMC simulator device and an IPMI BT device at machine initialization time. We loose the ability to define an external BMC device but there are benefits: - a better match with real systems, - a better test coverage of the OPAL code, - system powerdown and reset commands that work, - a QEMU device tree compliant with the specifications (*). (*) Still needs a MBOX device. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191121162340.11049-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add HIOMAP commandsCédric Le Goater2019-12-171-0/+1
| | | | | | | | | | | | | | | This activates HIOMAP support on the QEMU PowerNV machine. The PnvPnor model is used to access the flash contents. The model simply maps the contents at a fix offset and enables or disables the mapping. HIOMAP Protocol description : https://github.com/openbmc/hiomapd/blob/master/Documentation/protocol.md Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191028070027.22752-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Link "chip" property to PnvXive::chip pointerGreg Kurz2019-12-171-2/+2
| | | | | | | | | | | The XIVE object has both a pointer and a "chip" property pointing to the chip object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383336564.165747.10250365296928442882.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Link "chip" property to PnvCore::chip pointerGreg Kurz2019-12-171-2/+2
| | | | | | | | | | | The core object has both a pointer and a "chip" property pointing to the chip object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383336007.165747.1524120147081367440.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Link "chip" property to PnvHomer::chip pointerGreg Kurz2019-12-171-4/+4
| | | | | | | | | | | The homer object has both a pointer and a "chip" property pointing to the chip object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383335451.165747.32301068645427993.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Link "psi" property to PnvOCC::psi pointerGreg Kurz2019-12-171-4/+4
| | | | | | | | | | | The OCC object has both a pointer and a "psi" property pointing to the PSI object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383334894.165747.7617090757862105199.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Link "psi" property to PnvLpc::psi pointerGreg Kurz2019-12-171-4/+4
| | | | | | | | | | | The LPC object has both a pointer and a "psi" property pointing to the PSI object. Confusing bugs could arise if these ever go out of sync. Change the property definition so that it explicitely sets the pointer. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383334342.165747.3159314903077305653.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Drop "chip" link from POWER9 PSI objectGreg Kurz2019-12-171-2/+0Star
| | | | | | | | It has no apparent user. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157383383118.166856.2588933416368211047.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add a "/qemu" device tree nodeCédric Le Goater2019-12-171-0/+3
| | | | | | | | | It helps skiboot identifying that is running on a QEMU platform. The compatible string will define the POWERPC processor version. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191106142129.4908-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Add a PNOR modelCédric Le Goater2019-12-171-0/+14
| | | | | | | | | | | On a POWERPC PowerNV system, the host firmware is stored in a PNOR flash chip which contents is mapped on the LPC bus. This model adds a simple dummy device to map the contents of a block device in the host address space. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191021131215.3693-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc: Add intc_destroy() handlers to SpaprInterruptController/PnvChipGreg Kurz2019-11-181-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | SpaprInterruptControllerClass and PnvChipClass have an intc_create() method that calls the appropriate routine, ie. icp_create() or xive_tctx_create(), to establish the link between the VCPU and the presenter component of the interrupt controller during realize. There aren't any symmetrical call to be called when the VCPU gets unrealized though. It is assumed that object_unparent() is the only thing to do. This is questionable because the parenting logic around the CPU and presenter objects is really an implementation detail of the interrupt controller. It shouldn't be open-coded in the machine code. Fix this by adding an intc_destroy() method that undoes what was done in intc_create(). Also NULLify the presenter pointers to avoid having stale pointers around. This will allow to reliably check if a vCPU has a valid presenter. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157192724208.3146912.7254684777515287626.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
* hw: Move MC146818 device from hw/timer/ to hw/rtc/ subdirectoryPhilippe Mathieu-Daudé2019-10-241-1/+1
| | | | | | | | | | | | | The MC146818 is a Real Time Clock, not a timer. Move it under the hw/rtc/ subdirectory. Use copyright statement from 80cabfad163 for "hw/rtc/mc146818rtc.h". Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191003230404.19384-4-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* ppc: Reset the interrupt presenter from the CPU reset handlerCédric Le Goater2019-10-241-0/+18
| | | | | | | | | | | | | | | | | | | | | On the sPAPR machine and PowerNV machine, the interrupt presenters are created by a machine handler at the core level and are reset independently. This is not consistent and it raises issues when it comes to handle hot-plugged CPUs. In that case, the presenters are not reset. This is less of an issue in XICS, although a zero MFFR could be a concern, but in XIVE, the OS CAM line is not set and this breaks the presenting algorithm. The current code has workarounds which need a global cleanup. Extend the sPAPR IRQ backend and the PowerNV Chip class with a new cpu_intc_reset() handler called by the CPU reset handler and remove the XiveTCTX reset handler which is now redundant. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191022163812.330-6-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* ppc/pnv: Remove the XICSFabric Interface from the POWER9 machineCédric Le Goater2019-10-041-17/+14Star
| | | | | | | | | | | | | | | The POWER8 PowerNV machine needs to implement a XICSFabric interface as this is the POWER8 interrupt controller model. But the POWER9 machine uselessly inherits of XICSFabric from the common PowerNV machine definition. Open code machine definitions to have a better control on the different interfaces each machine should define. Fixes: f30c843ced50 ("ppc/pnv: Introduce PowerNV machines with fixed CPU models") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191003143617.21682-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/pnv_homer: add PowerNV homer device modelBalamuruhan S2019-10-041-0/+30
| | | | | | | | | | | add PnvHomer device model to emulate homer memory access for pstate table, occ-sensors, slw, occ static and dynamic values for Power8 and Power9 chips. Signed-off-by: Balamuruhan S <bala24@linux.ibm.com> Message-Id: <20190912093056.4516-4-bala24@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/pnv_occ: add sram device model for occ common areaBalamuruhan S2019-10-041-0/+8
| | | | | | | | | | | emulate occ common area region with occ sram device model which occ and skiboot uses it to communicate regarding sensors, slw and HWMON in PowerNV emulated host. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Balamuruhan S <bala24@linux.ibm.com> Message-Id: <20190912093056.4516-3-bala24@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* hw/ppc/pnv: fix checkpatch.pl coding style warningsBalamuruhan S2019-10-041-17/+32
| | | | | | | | | | | There were few trailing comments after `/*` instead in new line and line more than 80 character, these fixes are trivial and doesn't change any logic in code. Signed-off-by: Balamuruhan S <bala24@linux.ibm.com> Message-Id: <20190911142925.19197-5-bala24@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>