From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? Date: Thu, 19 Jan 2012 18:38:01 +0100 Message-ID: <4F1854F9.6030400@siemens.com> References: <4F17D56F.9090309@siemens.com> <20120119172532.GC11381@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm , qemu-devel To: Marcelo Tosatti Return-path: Received: from thoth.sbs.de ([192.35.17.2]:27520 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752112Ab2ASRiJ (ORCPT ); Thu, 19 Jan 2012 12:38:09 -0500 In-Reply-To: <20120119172532.GC11381@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-01-19 18:25, Marcelo Tosatti wrote: > On Thu, Jan 19, 2012 at 09:33:51AM +0100, Jan Kiszka wrote: >> Hi all, >> >> I've finished a first version of cleaned-up in-kernel KVM PIT support. >> That will be rolled out once the base support for irqchip has been merged. >> >> I'm now wondering if and how to model two control knobs we have in qemu-kvm: >> >> o -no-kvm-pit, ie. disable the in-kernel PIT even when {A,IOA,}PIC >> are kernel based (default: off, ie. use in-kernel PIT) > > It can be useful for debugging. When was it last? The kernel model should be stable by now, just possibly incomplete. But then there is still the full emulation in user mode, available via kernel_irqchip=off. We can control it, the question is if we really need the granularity. > >> o -no-kvm-pit-reinjection, ie. control over the lost ticks reinjection >> logic in the kernel (default: off, ie. do reinject) > > If the guest kernel does not compensate for lost ticks, reinjection is > needed. Otherwise, it might cause problems. That's why it's /on/ by default? What problems does it cause, and in which scenarios? Can't they be fixed? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnvwC-0000iZ-PS for qemu-devel@nongnu.org; Thu, 19 Jan 2012 12:38:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rnvw6-0004nJ-CW for qemu-devel@nongnu.org; Thu, 19 Jan 2012 12:38:12 -0500 Received: from thoth.sbs.de ([192.35.17.2]:26569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rnvw6-0004nD-35 for qemu-devel@nongnu.org; Thu, 19 Jan 2012 12:38:06 -0500 Message-ID: <4F1854F9.6030400@siemens.com> Date: Thu, 19 Jan 2012 18:38:01 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F17D56F.9090309@siemens.com> <20120119172532.GC11381@amt.cnet> In-Reply-To: <20120119172532.GC11381@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: qemu-devel , kvm On 2012-01-19 18:25, Marcelo Tosatti wrote: > On Thu, Jan 19, 2012 at 09:33:51AM +0100, Jan Kiszka wrote: >> Hi all, >> >> I've finished a first version of cleaned-up in-kernel KVM PIT support. >> That will be rolled out once the base support for irqchip has been merged. >> >> I'm now wondering if and how to model two control knobs we have in qemu-kvm: >> >> o -no-kvm-pit, ie. disable the in-kernel PIT even when {A,IOA,}PIC >> are kernel based (default: off, ie. use in-kernel PIT) > > It can be useful for debugging. When was it last? The kernel model should be stable by now, just possibly incomplete. But then there is still the full emulation in user mode, available via kernel_irqchip=off. We can control it, the question is if we really need the granularity. > >> o -no-kvm-pit-reinjection, ie. control over the lost ticks reinjection >> logic in the kernel (default: off, ie. do reinject) > > If the guest kernel does not compensate for lost ticks, reinjection is > needed. Otherwise, it might cause problems. That's why it's /on/ by default? What problems does it cause, and in which scenarios? Can't they be fixed? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux