On 7/10/25 17:39, Stefano Stabellini wrote: > 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.
Curious: why is the RTOS running on an x86 core at all, and not on a microcontroller dedicated exclusively to real-time tasks? The performance impact of isolating the RTOS from other tasks seems huge compared to the cost of a tiny microcontroller that just runs the RTOS. Have you considered upstreaming the patch? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
