Re: [PATCH 0/8] use jump labels to streamline common APIC configuration

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-08-14 16:37, Gleb Natapov wrote:
> On Tue, Aug 14, 2012 at 04:20:06PM +0200, Jan Kiszka wrote:
>> On 2012-08-14 16:03, Gleb Natapov wrote:
>>> On Tue, Aug 14, 2012 at 04:00:54PM +0200, Jan Kiszka wrote:
>>>> On 2012-08-05 16:03, Gleb Natapov wrote:
>>>>> On Sun, Aug 05, 2012 at 05:00:37PM +0300, Avi Kivity wrote:
>>>>>> On 08/05/2012 04:48 PM, Gleb Natapov wrote:
>>>>>>  >>
>>>>>>>>>> During guest boot up, some of these jump keys will change, no?  Does
>>>>>>>>>> this mean a stop_machine() or equivalent?  I'm worried about real-time
>>>>>>>>>> response or one guest being affected by another.
>>>>>>>>>>
>>>>>>>>> Yes, SW enable bit changes during boot. The jump label triggerable by a
>>>>>>>>> guest are rate limited though. So stop machine will not happen more then
>>>>>>>>> once per second even with malicious guests.
>>>>>>>>
>>>>>>>> I'm not talking about a malicious guest, just a guest that is booting up
>>>>>>>> normally but kills real-time response for another guest (or just induces
>>>>>>>> a large hiccup in a non-real-time guest, but we don't guarantee anything
>>>>>>>> for those).
>>>>>>>>
>>>>>>>> We don't support real-time guests now, but Jan has plans.
>>>>>>>>
>>>>>>> For such setup jump labels have to be compiled out from the kernel
>>>>>>> completely. Anything that calls stop_machine does not play well with
>>>>>>> real time.
>>>>>>>
>>>>>>> Guest can cause stop machine on boot today already by detecting PMU and
>>>>>>> configuring NMI watchdog.
>>>>>>
>>>>>> The host can prevent this by leaving disabling the guest pmu.  But
>>>>>> disabling jump labels for real-time kernels may be acceptable too.  We
>>>>>> can probably to it at run time by forcing the slow path at all times.
>>>>> Yes, it is possible to add module option that will force slow path if
>>>>> needed.
>>>>
>>>> Should I write a patch or will you? Having host-side stop_machine due to
>>>> such common guest operations is indeed a no-go for RT.
>>>>
>>> Do we support RT now? The operation are definitely not common.
>>
>> We also have min_timer_period_us to control the APIC timer - for the
>> same use case.
>>
>> And regarding how common they are: Do standard OSes trigger any
>> jump-label optimized switch during at least their boot-up? I thought so.
>> In that case, if you co-locate RT and standard OSes on a shared host,
>> you would have a conflict.
>>
> Yes, during boot up it happens. But it is rate limited to happen not
> more than once per second. But I genuinely curious does RT guest have
> any RT guaranties from QEMU/kvm combination today (with of without
> jump-labels)?

Yes, when avoiding userspace exits. If you have a customized RTOS guest
or are lucky with some existing one, that works pretty well for periodic
processing in the 1 ms range.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux