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. 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
