On 10.07.2025 09:02, Roger Pau Monné wrote: > On Wed, Jul 09, 2025 at 05:44:33PM -0700, Stefano Stabellini wrote: >> 2) means that the RTOS must be undisturbed when executing the critical >> section, which is typically right after receiving the interrupt and only >> last for less than 1ms. In practice, it means the RTOS should absolutely >> not be descheduled and there should be no (unnecessary) traps into Xen >> while the RTOS is executing the critical section. It is expected that >> the RTOS will run the critical section with interrupts disabled. > > What about other external interrupts? While the guest runs the > critical interrupt handling section with interrupts disabled, an > external interrupt from a device targeting the pCPU could cause a > vmexit.
For interrupts to be handled by the guest, we may need to finally gain AVIC support (albeit I'm not sure how close that is to VMX-es posted interrupts). For interrupts handled in Xen the only way would be to allow the guest to announce such critical sections to Xen. Which, besides being a security concern, may of course itself represent unacceptable overhead. Jan > I'm not aware of a nice way to solve this however, as for > PVH/HVM Xen doesn't know when the guest has finished interrupt > processing (iret). Maybe this is not an issue in practice if you > isolate interrupts to different vCPUs (you might have to do this > already to ensure deterministic latency). > > Roger.
