Re: [PATCH 0/2] Xen real-time x86

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2290 bytes --]

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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]