From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42259 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PcZ8n-0003FZ-Np for qemu-devel@nongnu.org; Tue, 11 Jan 2011 02:59:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PcZ8m-0001Pb-Id for qemu-devel@nongnu.org; Tue, 11 Jan 2011 02:59:41 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:45587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PcZ8m-0001PV-EE for qemu-devel@nongnu.org; Tue, 11 Jan 2011 02:59:40 -0500 Received: by wyg36 with SMTP id 36so22190527wyg.4 for ; Mon, 10 Jan 2011 23:59:39 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4D2C0E05.605@redhat.com> Date: Tue, 11 Jan 2011 09:00:05 +0100 From: Paolo Bonzini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state References: <4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de> <4D2B8662.9060909@web.de> In-Reply-To: <4D2B8662.9060909@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , kvm@vger.kernel.org, Glauber Costa , Marcelo Tosatti , qemu-devel@nongnu.org On 01/10/2011 11: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. The pointer property uses, at least last time I checked, were all: 1) for a CPU (apic, etrax interrupt controller) 2) for a device (sparc IIRC) 3) useless (smbus_eeprom.c) So adding a fourth kind is not really a good idea, I think. Paolo