From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Date: Mon, 10 Jan 2011 17:02:16 -0600 Message-ID: <4D2B8FF8.7070600@linux.vnet.ibm.com> References: <4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de> <4D2B8662.9060909@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Glauber Costa , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from e8.ny.us.ibm.com ([32.97.182.138]:55058 "EHLO e8.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754960Ab1AJXDA (ORCPT ); Mon, 10 Jan 2011 18:03:00 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0AMjqa6012608 for ; Mon, 10 Jan 2011 17:45:52 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 794AD4DE803B for ; Mon, 10 Jan 2011 17:59:59 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0AN2wuY408474 for ; Mon, 10 Jan 2011 18:02:59 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0AN2wkN031306 for ; Mon, 10 Jan 2011 18:02:58 -0500 In-Reply-To: <4D2B8662.9060909@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 01/10/2011 04:21 PM, Jan Kiszka wrote: > Am 10.01.2011 22:06, Jan Kiszka wrote: > >>> kvmclock should be created with >>> kvm_state as a parameter and kvm_vm_ioctl() is passed the stored >>> reference. Taking a global reference to kvm_state in machine_init is >>> not a bad thing, obviously the machine initialization function needs >>> access to the kvm_state. >>> >> This would also require changing sysbus interfaces for the sake of KVM's >> "abstraction". If this is the only way forward, I could look into this. >> > Actually, there is already a channel to pass pointers to qdev devices: > the pointer property hack. I'm not sure we should contribute to its user > base or take the chance for a cleanup, but we are not alone with this > requirement. Point below remains valid, though. > It probably makes sense to have a KVMBus and not pass it as a property but rather have it access it from the KvmBusState. Regards, Anthony Liguori > >> Still, I do not see any benefit for the affected code. You then either >> need to "steal" a kvm_state reference from the first cpu or introduce a >> marvelous interface like kvm_get_state() to make this work from outside >> of the KVM core. >> >> > Jan >