Init helpers sometimes fail to rebuild after switching branches,
which results in runtime faults.
Fix this by adding missing DEPS_INCLUDE to the Makefile.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
When stopping a core cpu_gic_callback is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
v3->v4:
* make irqactions static
* collect RBs
v2->v3:
* no changes
v1->v2:
* use percpu actions
When stopping a core deinit_timer_interrupt is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
v3->v4:
* make irqactions static
* collect RBs
v2->v3:
* no changes
v1->v2:
* use percpu actions
With PCI disabled the build fails due to undefined struct
pci_host_bridge.
Add ifdef guard to pci-host-rcar4.h to not require the stuct being
defined when PCI support is disabled. All call sites are already covered
by HAS_PCI check, so no dummy implementations are needed.
Also move includes under the header guard to not break MISRA rules.
Fixes: 08b52c30be ("iommu/ipmmu-vmsa: Implement basic PCIE-IPMMU OSID support")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For IPMMU to be able to associate a specific PCI device with it's TLB
the BDF to OSID mapping needs to be set up in the host bridge. The
configured OSID is then emmited as a sideband data on the AXI bus during
PCI DMA transactions. OSID configuration registers are located in the
"app" region of the host bridge.
Map the "app" region on init and implement methods for setting up
BDF->OSID mappings
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Introduce an additional private data field in `dw_pcie_priv` to allow
vendors to store custom data without interfering with bridge->priv.
Also add get/set pair to make accesing that private data less
cumbersome.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
On Arm without pci-passthrough=on Xen does not know anything about
present PCI devices due to PHYSDEVOP_pci_device_add not executing. This
causes PHYSDEVOP_pci_device_reset to fail when trying to find the device
that is being reset and return ENODEV.
Add explicit is_pci_passthrough_enabled check to return a more
meaningful EOPNOTSUPP code.
This change should not affect x86 behavior as pci-passthrough is always
enabled there.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This option enables the system suspend support. This is the mechanism that
allows the system to be suspended to RAM and later resumed.
The patch introduces three options:
- HAS_SYSTEM_SUSPEND: indicates suspend support is available on the platform.
- SYSTEM_SUSPEND_ALWAYS_ON: used for architectures where suspend must always
be enabled.
- SYSTEM_SUSPEND: user-facing option to enable/disable suspend if supported.
Defaults to enabled if SYSTEM_SUSPEND_ALWAYS_ON is set and depends on
HAS_SYSTEM_SUSPEND.
On x86, both HAS_SYSTEM_SUSPEND and SYSTEM_SUSPEND_ALWAYS_ON are selected by
default, making suspend support always enabled. The options are designed to
be easily extensible to other architectures (e.g., PPC, RISC-V) as future
support is added.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Invocation of the CPU_UP_PREPARE notification
on ARM64 during resume causes a crash:
(XEN) [ 315.807606] Error bringing CPU1 up: -16
(XEN) [ 315.811926] Xen BUG at common/cpu.c:258
[...]
(XEN) [ 316.142765] Xen call trace:
(XEN) [ 316.146048] [<00000a0000202264>] enable_nonboot_cpus+0x128/0x1ac (PC)
(XEN) [ 316.153219] [<00000a000020225c>] enable_nonboot_cpus+0x120/0x1ac (LR)
(XEN) [ 316.160391] [<00000a0000278180>] suspend.c#system_suspend+0x4c/0x1a0
(XEN) [ 316.167476] [<00000a0000206b70>] domain.c#continue_hypercall_tasklet_handler+0x54/0xd0
(XEN) [ 316.176117] [<00000a0000226538>] tasklet.c#do_tasklet_work+0xb8/0x100
(XEN) [ 316.183288] [<00000a0000226920>] do_tasklet+0x68/0xb0
(XEN) [ 316.189077] [<00000a000026e120>] domain.c#idle_loop+0x7c/0x194
(XEN) [ 316.195644] [<00000a0000277638>] shutdown.c#halt_this_cpu+0/0x14
(XEN) [ 316.202383] [<0000000000000008>] 0000000000000008
Freeing per-CPU areas and setting __per_cpu_offset to INVALID_PERCPU_AREA
only occur when !park_offline_cpus and system_state is not SYS_STATE_suspend.
On ARM64, park_offline_cpus is always false, so setting __per_cpu_offset to
INVALID_PERCPU_AREA depends solely on the system state.
If the system is suspended, this area is not freed, and during resume, an error
occurs in init_percpu_area, causing a crash because INVALID_PERCPU_AREA is not
set and park_offline_cpus remains 0:
if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA )
return park_offline_cpus ? 0 : -EBUSY;
The same crash can occur on x86 if park_offline_cpus is set
to 0 during Xen resume.
Fixes: f75780d26b ("xen: move per-cpu area management into common code")
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Mykyta Poturai