[PATCH v2 00/10] Introduce eSPI support

Leonid Komarianskyi posted 10 patches 4 months, 1 week ago
Only 1 patches received!
There is a newer version of this series
xen/arch/arm/Kconfig                   |   9 +
xen/arch/arm/domain_build.c            |  10 +
xen/arch/arm/gic-v3.c                  | 172 +++++++++++++----
xen/arch/arm/gic.c                     |   7 +-
xen/arch/arm/include/asm/gic.h         |  26 +++
xen/arch/arm/include/asm/gic_v3_defs.h |  35 +++-
xen/arch/arm/include/asm/irq.h         |  26 +++
xen/arch/arm/include/asm/vgic.h        |  36 ++++
xen/arch/arm/irq.c                     |  34 +++-
xen/arch/arm/vgic-v3.c                 | 248 ++++++++++++++++++++++++-
xen/arch/arm/vgic.c                    | 155 +++++++++++++++-
11 files changed, 711 insertions(+), 47 deletions(-)
[PATCH v2 00/10] Introduce eSPI support
Posted by Leonid Komarianskyi 4 months, 1 week ago
Hello everyone!

### Background
Unlike the Linux kernel, which has supported extended shared peripheral
interrupts (eSPIs) since 2019 [1], Xen currently lacks support for this
interrupt range. For SoCs with GICv3.1+, this feature may be essential
because critical devices, such as consoles required for booting Xen
itself, may rely on eSPIs. Additionally, these platforms require eSPI
support for fully functional domains, as any device using eSPIs cannot
currently be used with Xen setups. Without eSPI support, Xen cannot run
properly on these platforms, significantly limiting its usability on
modern ARM hardware.

This patch series adds support for the extended shared peripheral
interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
and guest domains. The implementation uses a generic approach to handle
eSPIs, similar to regular SPIs, while maintaining compatibility with the
existing SPI range. Functionality remains unchanged for setups that do
not require eSPIs.

The series includes:
1) General refactoring of common IRQ operations with GIC registers to
improve code readability, simplify further maintenance and prepare the
key functions for eSPI implementation.
2) Introducing a new Kconfig option (default y) to enable or disable
eSPI support. Disabling this option prevents unnecessary resource
allocation for setups that do not require eSPIs.
3) Adding additional resources to store required information and operate
with up to 1024 interrupts from eSPI range.
4) Adjusting assertions and checks to pass verification for INTIDs in
the eSPI range.
5) Configuration of eSPI-specific registers during GIC initialization
for systems with GICv3.1+ hardware.
6) Enables eSPI MMIO emulation for vGIC, allowing guest domains to
access and operate within the eSPI's INTIDs.

[1] https://github.com/torvalds/linux/commit/211bddd210a6746e4fdfa9b6cdfbdb15026530a7
[2] https://developer.arm.com/documentation/198123/0302/Arm-GIC-fundamentals?lang=en

Changes in V2:
- added 2 more patches to implement helper
  functions for gic/vgic:
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
- removed 2 patches:
  xen/arm/irq: allow assignment/releasing of eSPI interrupts
  xen/arm: gic/irq: permit routing of eSPI interrupts to Xen and domains
  since their functionality can be moved to appropriate patches after
  introducing patches with helper functions
- individual changes in patches

Link on V1:
- https://lists.xenproject.org/archives/html/xen-devel/2025-07/msg01809.html

Leonid Komarianskyi (10):
  xen/arm: gicv3: refactor obtaining GIC addresses for common operations
  xen/arm: gic: implement helper functions for INTID checks
  xen/arm: vgic: implement helper functions for virq checks
  xen/arm/irq: add handling for IRQs in the eSPI range
  xen/arm: gicv3: implement handling of GICv3.1 eSPI
  xen/arm/irq: allow eSPI processing in the do_IRQ function
  xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing
  xen/arm: vgic: add resource management for extended SPIs
  xen/arm: domain_build: adjust Dom0 IRQ handling to support eSPIs
  xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers

 xen/arch/arm/Kconfig                   |   9 +
 xen/arch/arm/domain_build.c            |  10 +
 xen/arch/arm/gic-v3.c                  | 172 +++++++++++++----
 xen/arch/arm/gic.c                     |   7 +-
 xen/arch/arm/include/asm/gic.h         |  26 +++
 xen/arch/arm/include/asm/gic_v3_defs.h |  35 +++-
 xen/arch/arm/include/asm/irq.h         |  26 +++
 xen/arch/arm/include/asm/vgic.h        |  36 ++++
 xen/arch/arm/irq.c                     |  34 +++-
 xen/arch/arm/vgic-v3.c                 | 248 ++++++++++++++++++++++++-
 xen/arch/arm/vgic.c                    | 155 +++++++++++++++-
 11 files changed, 711 insertions(+), 47 deletions(-)

-- 
2.34.1
Re: [PATCH v2 00/10] Introduce eSPI support
Posted by Oleksandr Tyshchenko 3 months, 3 weeks ago

On 07.08.25 15:33, Leonid Komarianskyi wrote:
> Hello everyone!

Hello Leonid,

> 
> ### Background
> Unlike the Linux kernel, which has supported extended shared peripheral
> interrupts (eSPIs) since 2019 [1], Xen currently lacks support for this
> interrupt range. For SoCs with GICv3.1+, this feature may be essential
> because critical devices, such as consoles required for booting Xen
> itself, may rely on eSPIs. Additionally, these platforms require eSPI
> support for fully functional domains, as any device using eSPIs cannot
> currently be used with Xen setups. Without eSPI support, Xen cannot run
> properly on these platforms, significantly limiting its usability on
> modern ARM hardware.
> 
> This patch series adds support for the extended shared peripheral
> interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
> and guest domains. The implementation uses a generic approach to handle
> eSPIs, similar to regular SPIs, while maintaining compatibility with the
> existing SPI range. Functionality remains unchanged for setups that do
> not require eSPIs.


I have lightly re-checked the simple Arm64 Xen environment (dom0less 
DomU under QEMU) with your series applied. To be clear, I did not really 
test the eSPI support (the underlying GICv3 HW does support it); I just 
wanted to ensure that your series would not break anything. So, in both 
cases (CONFIG_GICV3_ESPI=y and CONFIG_GICV3_ESPI=n), I did not notice 
any issues (at least obvious) related to GICv3 emulation and SPI 
injection for the passed-through device.

Also, I think you want to describe the eSPI feature in the CHANGELOG.md.


[snip]
Re: [PATCH v2 00/10] Introduce eSPI support
Posted by Leonid Komarianskyi 3 months, 3 weeks ago
Hello Oleksandr,

On 24.08.25 20:21, Oleksandr Tyshchenko wrote:
> 
> 
> On 07.08.25 15:33, Leonid Komarianskyi wrote:
>> Hello everyone!
> 
> Hello Leonid,
> 
>>
>> ### Background
>> Unlike the Linux kernel, which has supported extended shared peripheral
>> interrupts (eSPIs) since 2019 [1], Xen currently lacks support for this
>> interrupt range. For SoCs with GICv3.1+, this feature may be essential
>> because critical devices, such as consoles required for booting Xen
>> itself, may rely on eSPIs. Additionally, these platforms require eSPI
>> support for fully functional domains, as any device using eSPIs cannot
>> currently be used with Xen setups. Without eSPI support, Xen cannot run
>> properly on these platforms, significantly limiting its usability on
>> modern ARM hardware.
>>
>> This patch series adds support for the extended shared peripheral
>> interrupt (eSPI) range (INTIDs 4096-5119 [2](ranges of INTIDs)) for Xen
>> and guest domains. The implementation uses a generic approach to handle
>> eSPIs, similar to regular SPIs, while maintaining compatibility with the
>> existing SPI range. Functionality remains unchanged for setups that do
>> not require eSPIs.
> 
> 
> I have lightly re-checked the simple Arm64 Xen environment (dom0less 
> DomU under QEMU) with your series applied. To be clear, I did not really 
> test the eSPI support (the underlying GICv3 HW does support it); I just 
> wanted to ensure that your series would not break anything. So, in both 
> cases (CONFIG_GICV3_ESPI=y and CONFIG_GICV3_ESPI=n), I did not notice 
> any issues (at least obvious) related to GICv3 emulation and SPI 
> injection for the passed-through device.
> 

Thank you for your verification and proving that all works as expected 
on setup without HW eSPI support:)

> Also, I think you want to describe the eSPI feature in the CHANGELOG.md.
> 
> 
> [snip]

Okay, I will add one more patch in V3 to update the CHANGELOG.md file.

Best regards,
Leonid