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)? -- Gleb. -- 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
