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 17:03:05 +0300 Message-ID: <20120805140305.GN27579@redhat.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> 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]:16458 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752983Ab2HEODI (ORCPT ); Sun, 5 Aug 2012 10:03:08 -0400 Content-Disposition: inline In-Reply-To: <501E7C85.70001@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- Gleb.