From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 15/15] kvm: x86: Introduce kvmclock device to save/restore its state Date: Mon, 07 Feb 2011 14:44:17 +0200 Message-ID: <4D4FE921.8030805@redhat.com> References: <1297081668.14123.2.camel@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Glauber Costa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17523 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770Ab1BGMob (ORCPT ); Mon, 7 Feb 2011 07:44:31 -0500 In-Reply-To: <1297081668.14123.2.camel@mothafucka.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/2011 02:27 PM, Glauber Costa wrote: > > > What exactly is your motivation to that ? I think mid/long-term > we should be making machine initialization more common among > architectures, not introducing more arch specific, or even worse, kvm > specific parameters here. > A general note: there are several ways of being "kvm specific"; one of them is being tied to the implementation of kvm as the implementation of a virtual cpu in qemu. Another, with an example here, is a cpu feature that is only (or at first) present in kvm, but in principle may be supported by any cpu implementation, like tcg or a real cpu. It's important not to confuse the two; only the first needs all those hooks tied into the -accel infrastructure. -- error compiling committee.c: too many arguments to function