On 08.07.2025 19:11, Stefano Stabellini wrote: > On Tue, 8 Jul 2025, Jan Beulich wrote: >> On 08.07.2025 12:11, Roger Pau Monné wrote: >>> On Mon, Jul 07, 2025 at 05:06:53PM -0700, Stefano Stabellini wrote: >>>> Hi all, >>>> >>>> This short patch series improves Xen real-time execution on AMD x86 >>>> processors. >>>> >>>> The key to real-time performance is deterministic guest execution times >>>> and deterministic guest interrupt latency. In such configurations, the >>>> null scheduler is typically used, and there should be no IPIs or other >>>> sources of vCPU execution interruptions beyond the guest timer interrupt >>>> as configured by the guest, and any passthrough interrupts for >>>> passthrough devices. >>>> >>>> This is because, upon receiving a critical interrupt, the guest (such as >>>> FreeRTOS or Zephyr) typically has a very short window of time to >>>> complete the required action. Being interrupted in the middle of this >>>> critical section could prevent the guest from completing the action >>>> within the allotted time, leading to malfunctions. >>> >>> There's IMO still one pending issue after this series on x86, maybe >>> you have addressed this with some local patch. >> >> Not just one, I think. We use IPIs for other purposes as well. The way >> I read the text above, all of them are a (potential) problem. > > Yes, all of them are potentially a problem. If you know of any other > IPI, please let me know and I'll try to remove them.
INVALIDATE_TLB_VECTOR, EVENT_CHECK_VECTOR, and CALL_FUNCTION_VECTOR, maybe also others in that group of vectors (see irq-vectors.h). > One of my goals > posting this series was to raise awareness on this issue and attempting > to fix it with your help. It is not just IPIs, also Xen timers and other > things that could cause the guest to trap into Xen without the guest > knowledge. Typically IPIs are the worst offenders in my experience. > > On ARM, I have done several experiments where, after the system is > configured correctly, I can see that if the RTOS does nothing, there are > no traps in Xen on the RTOS vCPU/pCPU for seconds. Being quiescent when the system is idle is only part of the overall requirement, though? Jan
