[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 0/2] Xen real-time x86
On Thu, 10 Jul 2025, Jan Beulich wrote: > 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. In the past, I wrote a patch for an ARM user basically to do what you suggested: "announce such critical sections to Xen". It is easy for Xen to know when the critical section start: upon receiving the critical interrupt. I added an hypercall so that the RTOS could tell Xen when it ends. This is the kind of dirty patch that is very effective but difficult to generalize. As an example, you can pause all other VMs during the critical section to make sure the RTOS has full bandwidth on the bus. The critical section is much shorter than a scheduler slot anyway. I did not try to upstream the patch. > > 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). Yeah, that should be solvable by moving around other interrupts to other pCPUs.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |