From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? Date: Thu, 19 Jan 2012 15:25:32 -0200 Message-ID: <20120119172532.GC11381@amt.cnet> References: <4F17D56F.9090309@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm , qemu-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23982 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755508Ab2ASRcv (ORCPT ); Thu, 19 Jan 2012 12:32:51 -0500 Content-Disposition: inline In-Reply-To: <4F17D56F.9090309@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > 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. Therefore this option is needed. > So far I dropped the former and modeled the latter via a qdev property. > But I tend to think that even the latter knob is superfluous. In that > case I would also deprecate the original switches in qemu-kvm, just like > recently done with -tdf. > > Other thoughts? > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html