|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH 00/19] GICv4 Support for Xen
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 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 |