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: Tue, 11 Jan 2011 07:54:03 -0600 Message-ID: <4D2C60FB.7030009@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: Jan Kiszka , Marcelo Tosatti , Glauber Costa , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Markus Armbruster Return-path: Received: from e3.ny.us.ibm.com ([32.97.182.143]:40659 "EHLO e3.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753540Ab1AKNy5 (ORCPT ); Tue, 11 Jan 2011 08:54:57 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BDZxp3014445 for ; Tue, 11 Jan 2011 08:36:07 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id BF7394DE803F for ; Tue, 11 Jan 2011 08:51:54 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0BDstx0177340 for ; Tue, 11 Jan 2011 08:54:55 -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 p0BDstcj023030 for ; Tue, 11 Jan 2011 08:54:55 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 01/11/2011 03:31 AM, Markus Armbruster wrote: > Jan Kiszka writes: > > >> 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 >> > We shouldn't. > Right, we should introduce a KVMBus that KVM devices are created on. The devices can get at KVMState through the BusState. Regards, Anthony Liguori >> or take the chance for a cleanup, but we are not alone with this >> requirement. Point below remains valid, though. >> >> >>> 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. >>>