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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
