From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXYiL-0005pN-7o for qemu-devel@nongnu.org; Mon, 05 Dec 2011 08:36:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXYiF-00087D-HG for qemu-devel@nongnu.org; Mon, 05 Dec 2011 08:36:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXYiF-000873-93 for qemu-devel@nongnu.org; Mon, 05 Dec 2011 08:36:07 -0500 Date: Mon, 5 Dec 2011 11:35:44 -0200 From: Marcelo Tosatti Message-ID: <20111205133544.GA32052@amt.cnet> References: <1322853560-24152-1-git-send-email-emunson@mgebm.net> <4ED9331B.9060708@web.de> <20111202212726.GA5662@mgebm.net> <4ED9E6B0.2000903@web.de> <20111203111935.GA25573@amt.cnet> <4EDA0731.80302@web.de> <20111203114241.GA25871@amt.cnet> <4EDA0BEF.7010204@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EDA0BEF.7010204@web.de> Subject: Re: [Qemu-devel] [PATCH V3] Guest stop notification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "@amt.cnet@amt.cnet, Eric B Munson , ryanh@linux.vnet.ibm.com , aliguori@us.ibm.com , kvm@vger.kernel.org , qemu-devel@nongnu.org" , Avi Kivity On Sat, Dec 03, 2011 at 12:45:51PM +0100, Jan Kiszka wrote: > >> I was referring to the relation between the IOCTL and kvmclock, but > >> IOCTL vs. kvm_run. > >> > >> Jan > > > > Ah, OK. Yes, we better characterize it as KVMCLOCK specific (a generic > > "guest is paused" command is not the scope of this patch). > > > > So appending KVMCLOCK_ to the ioctl definitions would make that more > > explicit. > > IMHO, that would move things in the wrong direction. The IOCTL in itself > has _nothing_ to do with kvmclock. It's just that its x86 backend is > implemented on top of that infrastructure. For me the IOCTL is pretty > generic, can be backed by kvmclock, but need not be on all future archs. > > Jan I do not see the need to lift this infrastructure to arch independent status at the moment, without clear semantics on that arch independent level. So I am fine with the current GUEST_PAUSED naming (which can later be extended with GUEST_RESUMED etc, if necessary, for use by other archs for example), and implementation in hw/kvmclock.c.