From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 0/8] use jump labels to streamline common APIC configuration Date: Tue, 14 Aug 2012 16:58:52 +0200 Message-ID: <502A67AC.3000209@siemens.com> References: <1344171513-4659-1-git-send-email-gleb@redhat.com> <501E760E.9050109@redhat.com> <20120805133549.GL27579@redhat.com> <501E7839.2030008@redhat.com> <20120805134842.GM27579@redhat.com> <501E7C85.70001@redhat.com> <20120805140305.GN27579@redhat.com> <502A5A16.6040506@siemens.com> <20120814140348.GM11194@redhat.com> <502A5E96.6090908@siemens.com> <20120814143758.GP11194@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "kvm@vger.kernel.org" , "mtosatti@redhat.com" To: Gleb Natapov Return-path: Received: from thoth.sbs.de ([192.35.17.2]:30278 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911Ab2HNO65 (ORCPT ); Tue, 14 Aug 2012 10:58:57 -0400 In-Reply-To: <20120814143758.GP11194@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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