|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH 00/19] GICv4 Support for Xen
Hi Mykyta, > On 3 Feb 2026, at 13:24, Mykyta Poturai <Mykyta_Poturai@xxxxxxxx> wrote: > > On 03.02.26 12:01, Bertrand Marquis wrote: >> Hi Mykyta, >> >> We have a number of series from you which have not been merged yet and >> reviewing them all in parallel might be challenging. >> >> Would you mind giving us a status and maybe priorities on them. >> >> I could list the following series: >> - GICv4 >> - CPU Hotplug on arm >> - PCI enumeration on arm >> - IPMMU for pci on arm >> - dom0less for pci passthrough on arm >> - SR-IOV for pvh >> - SMMU for pci on arm >> - MSI injection on arm >> - suspend to ram on arm >> >> There might be others feel free to complete the list. >> >> On GICv4... >> >>> On 2 Feb 2026, at 17:14, Mykyta Poturai <Mykyta_Poturai@xxxxxxxx> wrote: >>> >>> This series introduces GICv4 direct LPI injection for Xen. >>> >>> Direct LPI injection relies on the GIC tracking the mapping between >>> physical and >>> virtual CPUs. Each VCPU requires a VPE that is created and registered with >>> the >>> GIC via the `VMAPP` ITS command. The GIC is then informed of the current >>> VPE-to-PCPU placement by programming `VPENDBASER` and `VPROPBASER` in the >>> appropriate redistributor. LPIs are associated with VPEs through the >>> `VMAPTI` >>> ITS command, after which the GIC handles delivery without trapping into the >>> hypervisor for each interrupt. >>> >>> When a VPE is not scheduled but has pending interrupts, the GIC raises a >>> per-VPE >>> doorbell LPI. Doorbells are owned by the hypervisor and prompt rescheduling >>> so >>> the VPE can drain its pending LPIs. >>> >>> Because GICv4 lacks a native doorbell invalidation mechanism, this series >>> includes a helper that invalidates doorbell LPIs via synthetic “proxy” >>> devices, >>> following the approach used until GICv4.1. >>> >>> All of this work is mostly based on the work of Penny Zheng >>> <penny.zheng@xxxxxxx> and Luca Fancellu <luca.fancellu@xxxxxxx>. And also >>> from >>> Linux patches by Mark Zyngier. >>> >>> Some patches are still a little rough and need some styling fixes and more >>> testing, as all of them needed to be carved line by line from a giant ~4000 >>> line >>> patch. This RFC is directed mostly to get a general idea if the proposed >>> approach is suitable and OK with everyone. And there is still an open >>> question >>> of how to handle Signed-off-by lines for Penny and Luca, since they have not >>> indicated their preference yet. >> >> I would like to ask how much performance benefits you could >> have with this. >> Adding GICv4 support is adding a lot of code which will have to be maintained >> and tested and there should be a good improvement to justify this. >> >> Did you do some benchmarks ? what are the results ? >> >> At the time where we started to work on that at Arm, we ended up in the >> conclusion >> that the complexity in Xen compared to the benefit was not justifying it >> hence why >> this work was stopped in favor of other features that we thought would be >> more >> beneficial to Xen (like PCI passthrough or SMMUv3). >> >> Cheers >> Bertrand >> > > Hi Bertrand > > Current priorities are: > > - CPU hotplug > - Suspend to RAM > - GICv4 (we will follow up with benchmarks) > - SR-IOV > Ok Let's focus on what is already there and being reviewed before GICv4. I will follow up and your CPU hotplug review and suspend to RAM is already advanced so we should focus on finishing those first. Cheers Bertrand > > MSI injection, dom0less for pci and PCI enumeration are low priority for now > > Suspend to RAM is handled by Mykola Kvach > > SMMU and IPMMU support are merged already AFAIU > > -- > Mykyta
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |