From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 0/8] use jump labels to streamline common APIC configuration Date: Sun, 5 Aug 2012 16:48:42 +0300 Message-ID: <20120805134842.GM27579@redhat.com> References: <1344171513-4659-1-git-send-email-gleb@redhat.com> <501E760E.9050109@redhat.com> <20120805133549.GL27579@redhat.com> <501E7839.2030008@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, mtosatti@redhat.com, Jan Kiszka To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40758 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751316Ab2HENsq (ORCPT ); Sun, 5 Aug 2012 09:48:46 -0400 Content-Disposition: inline In-Reply-To: <501E7839.2030008@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Aug 05, 2012 at 04:42:17PM +0300, Avi Kivity wrote: > On 08/05/2012 04:35 PM, Gleb Natapov wrote: > > On Sun, Aug 05, 2012 at 04:33:02PM +0300, Avi Kivity wrote: > >> On 08/05/2012 03:58 PM, Gleb Natapov wrote: > >> > APIC code has a lot of checks for apic presence and apic HW/SW enable > >> > state. Most common configuration is when each vcpu has in kernel apic > >> > and it is fully enabled. This path series uses jump labels to turn checks > >> > to nops in the common case. > >> > > >> > Gleb Natapov (8): > >> > KVM: clean up kvm_(set|get)_apic_base > >> > KVM: use kvm_lapic_set_base() to change apic_base > >> > KVM: mark apic enabled on start up. > >> > Export jump_label_rate_limit() > >> > KVM: use jump label to optimize checking for HW enabled APIC in > >> > APIC_BASE MSR. > >> > KVM: use jump label to optimize checking for SW enabled apic in > >> > spurious interrupt register > >> > KVM: use jump label to optimize checking for in kernel local apic > >> > presence. > >> > KVM: inline kvm_apic_present() and kvm_lapic_enabled() > >> > >> Neat. > >> > >> 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. -- Gleb.