Re: [PATCH v2 00/10] Introduce eSPI support

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

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]