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
