From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] qemu-kvm: introduce cpu_start/cpu_stop commands Date: Mon, 22 Nov 2010 18:24:29 -0600 Message-ID: <4CEB09BD.2010804@linux.vnet.ibm.com> References: <1290466818-5230-1-git-send-email-aliguori@us.ibm.com> <20101122230405.GB10050@sequoia.sous-sol.org> <4CEB006C.8010407@linux.vnet.ibm.com> <20101122235651.GD10050@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Chris Wright Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:59810 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932065Ab0KWAYj (ORCPT ); Mon, 22 Nov 2010 19:24:39 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oAN0Cj4b023945 for ; Mon, 22 Nov 2010 17:12:45 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oAN0Obp1138442 for ; Mon, 22 Nov 2010 17:24:37 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oAN0Oa1G023449 for ; Mon, 22 Nov 2010 17:24:36 -0700 In-Reply-To: <20101122235651.GD10050@sequoia.sous-sol.org> Sender: kvm-owner@vger.kernel.org List-ID: On 11/22/2010 05:56 PM, Chris Wright wrote: > * Anthony Liguori (aliguori@linux.vnet.ibm.com) wrote: > >> On 11/22/2010 05:04 PM, Chris Wright wrote: >> >>> * Anthony Liguori (aliguori@us.ibm.com) wrote: >>> >>>> qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching >>>> them to respond to these signals, introduce monitor commands that stop and start >>>> individual vcpus. >>>> >>> In the past SIGSTOP has introduced time skew. Have you verified this >>> isn't an issue. >>> >> Time skew is a big topic. Are you talking about TSC drift, >> pit/rtc/hpet drift, etc? >> > Sorry to be vague, but it's been long enough that I don't recall > the details. The guest kernel's clocksource effected how timekeeping > progressed across STOP/CONT (was probably missing qemu based timer ticks). > While this is not the same, made me wonder if you'd tested against that. > Yeah, it's definitely going to increase the likelihood of interrupt coalescing but only as much as a contended CPU would already. QEMU will keep getting timer ticks but the guest won't process them in a timely fashion. >> It's certainly going to stress periodic interrupt catch up code. >> > Heh, call it a feature for autotest ;) > Excellent idea :-) Regards, Anthony Liguori > thanks, > -chris >