- 10 Mar, 2016 6 commits
-
-
Sukadev Bhattiprolu authored
The Physical Core events of the 24x7 PMU can be monitored across various domains (physical core, vcpu home core, vcpu home node etc). For each of these core events, we currently create multiple events in sysfs, one for each domain the event can be monitored in. These events are distinguished by their suffixes like __PHYS_CORE, __VCPU_HOME_CORE etc. Rather than creating multiple such entries, we could let the user specify make 'domain' index a required parameter and let the user specify a value for it (like they currently specify the core index). $ cat /sys/bus/event_source/devices/hv_24x7/events/HPM_CCYC domain=?,offset=0x98,core=?,lpar=0x0 $ perf stat -C 0 -e hv_24x7/HPM_CCYC,domain=2,core=1/ true (the 'domain=?' and 'core=?' in sysfs tell perf tool to enforce them as required parameters). This simplifies the interface and allows users to identify events by the name specified in the catalog (User can determine the domain index by referring to '/sys/bus/event_source/devices/hv_24x7/interface/domains'). Eliminating the event suffix eliminates several functions and simplifies code. Note that Physical Chip events can only be monitored in the chip domain so those events have the domain set to 1 (rather than =?) and users don't need to specify the domain index for the Chip events. $ cat /sys/bus/event_source/devices/hv_24x7/events/PM_XLINK_CYCLES domain=1,offset=0x230,chip=?,lpar=0x0 $ perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES,chip=1/ true Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Sukadev Bhattiprolu authored
To help users determine domains, display the domain indices used by the kernel in sysfs. $ cat /sys/bus/event_source/devices/hv_24x7/interface/domains 1: Physical Chip 2: Physical Core 3: VCPU Home Core 4: VCPU Home Chip 5: VCPU Home Node 6: VCPU Remote Node Signed-off-by:
-
Sukadev Bhattiprolu authored
For 24x7 counters, perf displays the raw value of the 24x7 counter, which is a monotonically increasing value. perf stat -C 0 -e \ 'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \ sleep 1 Performance counter stats for 'CPU(s) 0': 9,105,403,170 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/ 0.000425751 seconds time elapsed In the typical usage of 'perf stat' this counter value is not as useful as the _change_ in the counter value over the duration of the application. Have h_24x7_event_init() set the event's prev_count to the raw value of the 24x7 counter at the time of initialization. When the application terminates, hv_24x7_event_read() will compute the change in value and report to the perf tool. Similarly, for the transaction interface, clear the event count to 0 at the beginning of the transaction. perf stat -C 0 -e \ 'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \ sleep 1 Performance counter stats for 'CPU(s) 0': 245,758 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/ 1.006366383 seconds time elapsed Signed-off-by: -
Sukadev Bhattiprolu authored
24x7 counters can belong to different domains (core, chip, virtual CPU etc). For events in the 'chip' domain, sysfs entry currently looks like: $ cd /sys/bus/event_source/devices/hv_24x7/events $ cat PM_XLINK_CYCLES__PHYS_CHIP domain=0x1,offset=0x230,core=?,lpar=0x0 where the required parameter, 'core=?' is specified with perf as: perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,core=1/ \ /bin/true This is inconsistent in that 'core' is a required parameter for a chip event. Instead, have the the sysfs entry display 'chip=?' for chip events: $ cd /sys/bus/event_source/devices/hv_24x7/events $ cat PM_XLINK_CYCLES__PHYS_CHIP domain=0x1,offset=0x230,chip=?,lpar=0x0 We also need to add a 'chip' entry in the sysfs format directory: $ ls /sys/bus/event_source/devices/hv_24x7/format chip core domain lpar offset vcpu ^^^^ (new) so the perf tool can automatically check usage and format the chip parameter correctly: $ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/ \ /bin/true Required parameter 'chip' not specified invalid or unsupported event: 'hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/' $ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/ \ /bin/true hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/: 0 6628908 6628908 Performance counter stats for 'CPU(s) 0': 0 hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/ 0.006606970 seconds time elapsed Signed-off-by:
-
Sukadev Bhattiprolu authored
Power8 supports a large number of events in each susbystem so when a user runs: perf stat -e branch-instructions sleep 1 perf stat -e L1-dcache-loads sleep 1 it is not clear as to which PMU events were monitored. Export the generic hardware and cache perf events for Power8 to sysfs, so users can precisely determine the PMU event monitored by the generic event. Eg: cat /sys/bus/event_source/devices/cpu/events/branch-instructions event=0x10068 $ cat /sys/bus/event_source/devices/cpu/events/L1-dcache-loads event=0x100ee Signed-off-by:
-
Sukadev Bhattiprolu authored
We used the PME_ prefix earlier to avoid some macro/variable name collisions. We have since changed the way we define/use the event macros so we no longer need the prefix. By dropping the prefix, we keep the the event macros consistent with their official names. Reported-by:
Michael Ellerman <ellerman@au1.ibm.com> Signed-off-by:
-
- 09 Mar, 2016 22 commits
-
-
Vaibhav Jain authored
Add a check at the beginning of cxl_probe function to ignore virtual pci devices created for each afu registered. This fixes the the errors messages logged about missing CXL vsec, when cxl probe is unable to find necessary vsec entries in device pci config space. The error message logged are of the form : cxl-pci 0004:00:00.0: ABORTING: CXL VSEC not found! cxl-pci 0004:00:00.0: cxl_init_adapter failed: -19 Cc: Ian Munsie <imunsie@au1.ibm.com> Cc: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Reviewed-by: fbarrat@linux.vnet.ibm.com Reviewed-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
-
Frederic Barrat authored
The cxl_get_phys_dev() API returns a struct device pointer which could belong to either a struct pci_dev (bare-metal) or platform_device (powerVM). To avoid potential problems in drivers, remove that API. It was introduced to allow drivers to read the VPD of the adapter, but the cxl driver now provides the cxl_pci_read_adapter_vpd() API for that purpose. Co-authored-by:
Christophe Lombard <clombard@linux.vnet.ibm.com> Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
-
Frederic Barrat authored
To read the adapter VPD, drivers can't rely on pci config APIs, as it wouldn't work on powerVM. cxl introduced a new kernel API especially for this, so start using it. Co-authored-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Signed-off-by:
-
Christophe Lombard authored
To ease debugging, add a few tracepoints around the cxl hcalls. Co-authored-by:
-
Christophe Lombard authored
Check the AFU state whenever an API is called. The hypervisor may issue a reset of the adapter when it detects a fault. When it happens, it launches an error recovery which will either move the AFU to a permanent failure state, or in the disabled state. If the AFU is found to be disabled, detach all existing contexts from it before issuing a AFU reset to re-enable it. Before detaching contexts, notify any kernel driver through the EEH callbacks of the AFU pci device. Co-authored-by:
-
Frederic Barrat authored
Like on bare-metal, the cxl driver creates a virtual PHB and a pci device for the AFU. The configuration space of the device is mapped to the configuration record of the AFU. Reuse the code defined in afu_cr_read8|16|32() when reading the configuration space of the AFU device. Even though the (virtual) AFU device is a pci device, the adapter is not. So a driver using the cxl kernel API cannot read the VPD of the adapter through the usual PCI interface. Therefore, we add a call to the cxl kernel API: ssize_t cxl_read_adapter_vpd(struct pci_dev *dev, void *buf, size_t count); Co-authored-by:
-
Frederic Barrat authored
Add new entry point to scan the device tree at boot in a guest, looking for cxl devices. Co-authored-by:
-
Christophe Lombard authored
The new flash.c file contains the logic to flash a new image on the adapter, through a hcall. It is an iterative process, with chunks of data of 1M at a time. There are also 2 phases: write and verify. The flash operation itself is driven from a user-land tool. Once flashing is successful, an rtas call is made to update the device tree with the new properties values for the adapter and the AFU(s) Add a new char device for the adapter, so that the flash tool can access the card, even if there is no valid AFU on it. Co-authored-by:
-
Christophe Lombard authored
Filter out a few adapter parameters which don't make sense in a guest. Document the changes. Co-authored-by:
-
Christophe Lombard authored
The new of.c file contains code to parse the device tree to find out about cxl adapters and AFUs. guest.c implements the guest-specific callbacks for the backend API. The process element ID is not known until the context is attached, so we have to separate the context ID assigned by the cxl driver from the process element ID visible to the user applications. In bare-metal, the 2 IDs match. Co-authored-by:
-
Christophe Lombard authored
Introduce sub-structures containing the bare-metal specific fields in the structures describing the adapter (struct cxl) and AFU (struct cxl_afu). Update all their references. Co-authored-by:
-
Christophe Lombard authored
The hypervisor calls provide an interface with a coherent platform facility and function. It matches version 0.16 of the 'PAPR changes' document. The following hcalls are supported: H_ATTACH_CA_PROCESS Attach a process element to a coherent platform function. H_DETACH_CA_PROCESS Detach a process element from a coherent platform function. H_CONTROL_CA_FUNCTION Allow the partition to manipulate or query certain coherent platform function behaviors. H_COLLECT_CA_INT_INFO Collect interrupt info about a coherent. platform function after an interrupt occurred H_CONTROL_CA_FAULTS Control the operation of a coherent platform function after a fault occurs. H_DOWNLOAD_CA_FACILITY Support for downloading a base adapter image to the coherent platform facility, and for validating the entire image after the download. H_CONTROL_CA_FACILITY Allow the partition to manipulate or query certain coherent platform facility behaviors. Co-authored-by: -
Christophe Lombard authored
The hcalls introduced for cxl use a possible new value: H_STATE (invalid state). Co-authored-by:
-
Frederic Barrat authored
The PSL interrupt cannot be multiplexed in a guest, as it is not supported by the hypervisor. So an interrupt will be allocated for it for each context. It will still be the first interrupt found in the first interrupt range, but is treated almost like any other AFU interrupt when creating/deleting the context. Only the handler is different. Rework the code so that the range 0 is treated like the other ranges. Co-authored-by:
-
Frederic Barrat authored
The context parameter when calling cxl_irq() should be strongly typed. Co-authored-by:
-
Frederic Barrat authored
A few functions are mostly common between bare-metal and guest and just need minor tuning. To avoid crowding the backend API, introduce a few 'if' based on the CPU being in HV mode. Co-authored-by:
-
Frederic Barrat authored
Rename a few functions, changing the 'cxl_' prefix to either 'cxl_pci_' or 'cxl_native_', to make clear that the implementation is bare-metal specific. Those functions will have an equivalent implementation for a guest in a later patch. Co-authored-by:
-
Frederic Barrat authored
The backend API (in cxl.h) lists some low-level functions whose implementation is different on bare-metal and in a guest. Each environment implements its own functions, and the common code uses them through function pointers, defined in cxl_backend_ops Co-authored-by:
-
Frederic Barrat authored
CXL kernel API was defining the process problem state area during context initialization, making it possible to map the problem state area before attaching the context. This won't work on a powerVM guest. So force the logical behavior, like in userspace: attach first, then map the problem state area. Remove calls to cxl_assign_psn_space during init. The function is already called on the attach paths. Co-authored-by:
-
Frederic Barrat authored
Move a few functions around to better separate code specific to bare-metal environment from code which will be commonly used between guest and bare-metal. Code specific to bare-metal is meant to be in native.c or pci.c only. It's basically anything which touches the card p1 registers, some p2 registers not needed from a guest and the PCI interface. Co-authored-by:
-
Christophe Lombard authored
Move around some functions which will be accessed from the bare-metal and guest environments. Code in native.c and pci.c is meant to be bare-metal specific. Other files contain code which may be shared with guests. Co-authored-by:
-
Andrew Donnellan authored
In eeh_pci_enable(), after making the request to set the new options, we call eeh_ops->wait_state() to check that the request finished successfully. At the moment, if eeh_ops->wait_state() returns 0, we return 0 without checking that it reflects the expected outcome. This can lead to callers further up the chain incorrectly assuming the slot has been successfully unfrozen and continuing to attempt recovery. On powernv, this will occur if pnv_eeh_get_pe_state() or pnv_eeh_get_phb_state() return 0, which in turn occurs if the relevant OPAL call returns OPAL_EEH_STOPPED_MMIO_DMA_FREEZE or OPAL_EEH_PHB_ERROR respectively. On pseries, this will occur if pseries_eeh_get_state() returns 0, which in turn occurs if RTAS reports that the PE is in the MMIO Stopped and DMA Stopped states. Obviously, none of these cases represent a successful completion of a request to thaw MMIO or DMA. Fix the check so that a wait_state() return value of 0 won't be considered successful for the EEH_OPT_THAW_MMIO or EEH_OPT_THAW_DMA cases. Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
- 08 Mar, 2016 12 commits
-
-
Gavin Shan authored
When eeh_dump_pe_log() is only called by eeh_slot_error_detail(), we already have the check that the PE isn't in PCI config blocked state in eeh_slot_error_detail(). So we needn't the duplicated check in eeh_dump_pe_log(). This removes the duplicated check in eeh_dump_pe_log(). No logical changes introduced. Signed-off-by:
-
Gavin Shan authored
When passing through SRIOV VFs to guest, we possibly encounter EEH error on PF. In this case, the VF PEs are put into frozen state. The error could be reported to guest before it's captured by the host. That means the guest could attempt to recover errors on VFs before host gets chance to recover errors on PFs. The VFs won't be recovered successfully. This enforces the recovery order for above case: the recovery on child PE in guest is hold until the recovery on parent PE in host is completed. Signed-off-by:
Russell Currey <ruscur@russell.cc> Signed-off-by:
-
Gavin Shan authored
When we have partial hotplug as part of the error recovery on PF, the VFs that are bound with vfio-pci driver will experience hotplug. That's not allowed. This checks if the VF PE is passed or not. If it does, we leave the VF without removing it. Signed-off-by:
-
Gavin Shan authored
When EEH error happened to the parent PE of those PEs that have been passed through to guest, the error is propagated to guest domain and the VFIO driver's error handlers are called. It's not correct as the error in the host domain shouldn't be propagated to guests and affect them. This adds one more limitation when calling EEH error handlers. If the PE has been passed through to guest, the error handlers won't be called. Signed-off-by:
-
Wei Yang authored
PFs are enumerated on PCI bus, while VFs are created by PF's driver. In EEH recovery, it has two cases: 1. Device and driver is EEH aware, error handlers are called. 2. Device and driver is not EEH aware, un-plug the device and plug it again by enumerating it. The special thing happens on the second case. For a PF, we could use the original pci core to enumerate the bus, while for VF we need to record the VFs which aer un-plugged then plug it again. Also The patch caches the VF index in pci_dn, which can be used to calculate VF's bus, device and function number. Those information helps to locate the VF's PCI device instance when doing hotplug during EEH recovery if necessary. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Acked-by:
-
Wei Yang authored
After PE reset, OPAL API opal_pci_reinit() is called on all devices contained in the PE to reinitialize them. While skiboot is not aware of VFs, we have to implement the function in kernel to reinitialize VFs after reset on PE for VFs. In this patch, two functions pnv_pci_fixup_vf_mps() and pnv_eeh_restore_vf_config() both manipulate the MPS of the VF, since for a VF it has three cases. 1. Normal creation for a VF In this case, pnv_pci_fixup_vf_mps() is called to make the MPS a proper value compared with its parent. 2. EEH recovery without VF removed In this case, MPS is stored in pci_dn and pnv_eeh_restore_vf_config() is called to restore it and reinitialize other part. 3. EEH recovery with VF removed In this case, VF will be removed then re-created. Both functions are called. First pnv_pci_fixup_vf_mps() is called to store the proper MPS to pci_dn and then pnv_eeh_restore_vf_config() is called to do proper thing. This introduces two functions: pnv_pci_fixup_vf_mps() to fixup the VF's MPS to make sure it is equal to parent's and store this value in pci_dn for future use. pnv_eeh_restore_vf_config() to re-initialize on VF by restoring MPS, disabling completion timeout, enabling SERR, etc. Signed-off-by:
-
Wei Yang authored
PEs for VFs don't have primary bus. So they have to have their own reset backend, which is used during EEH recovery. The patch implements the reset backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained in the PE. Signed-off-by:
-
Wei Yang authored
This creates PEs for VFs in the weak function pcibios_bus_add_device(). Those PEs for VFs are identified with newly introduced flag EEH_PE_VF so that we treat them differently during EEH recovery. Signed-off-by:
-
Wei Yang authored
VFs and their corresponding pdn are created and released dynamically when their PF's SRIOV capability is enabled and disabled. This creates and releases EEH devices for VFs when creating and releasing their pdn instances, which means EEH devices and pdn instances have same life cycle. Also, VF's EEH device is identified by (struct eeh_dev::physfn). Signed-off-by:
-
Wei Yang authored
This restricts the EEH address cache to use only the first 7 BARs. This makes __eeh_addr_cache_insert_dev() ignore PCI bridge window and IOV BARs. As the result of this change, eeh_addr_cache_get_dev() will return VFs from VF's resource addresses instead of parent PFs. This also removes PCI bridge check as we limit __eeh_addr_cache_insert_dev() to 7 BARs and this effectively excludes PCI bridges from being cached. Signed-off-by:
-
Wei Yang authored
As commit ac205b7b ("PCI: make sriov work with hotplug remove") indicates, VFs which is on the same PCI bus as their PF, should be removed before the PF. Otherwise, we might run into kernel crash at PCI unplugging time. This applies the above pattern to powerpc PCI hotplug path. Signed-off-by:
-
Wei Yang authored
This adds weak function pcibios_bus_add_device() for arch dependent code could do proper setup. For example, powerpc could setup EEH related resources for SRIOV VFs. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
