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, 18 Jan 2011 09:04:24 -0600 Message-ID: <4D35ABF8.9050700@linux.vnet.ibm.com> References: <4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de> <4D2B8662.9060909@web.de> <4D2C60FB.7030009@linux.vnet.ibm.com> <4D2D80ED.8030405@redhat.com> <4D2D82EE.20002@siemens.com> <4D35A39A.8000801@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Markus Armbruster , Marcelo Tosatti , Glauber Costa , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Jan Kiszka Return-path: Received: from e5.ny.us.ibm.com ([32.97.182.145]:39919 "EHLO e5.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943Ab1ARPEe (ORCPT ); Tue, 18 Jan 2011 10:04:34 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0IEef67025248 for ; Tue, 18 Jan 2011 09:41:09 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id EBD784DE8026 for ; Tue, 18 Jan 2011 10:01:17 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0IF4Vng2367656 for ; Tue, 18 Jan 2011 10:04:32 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0IF4Tcq011920 for ; Tue, 18 Jan 2011 10:04:31 -0500 In-Reply-To: <4D35A39A.8000801@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/18/2011 08:28 AM, Jan Kiszka wrote: > On 2011-01-12 11:31, Jan Kiszka wrote: > >> Am 12.01.2011 11:22, Avi Kivity wrote: >> >>> On 01/11/2011 03:54 PM, Anthony Liguori wrote: >>> >>>> Right, we should introduce a KVMBus that KVM devices are created on. >>>> The devices can get at KVMState through the BusState. >>>> >>> There is no kvm bus in a PC (I looked). We're bending the device model >>> here because a device is implemented in the kernel and not in >>> userspace. An implementation detail is magnified beyond all proportions. >>> >>> An ioapic that is implemented by kvm lives in exactly the same place >>> that the qemu ioapic lives in. An assigned pci device lives on the PCI >>> bus, not a KVMBus. If we need a pointer to KVMState, then we must find >>> it elsewhere, not through creating imaginary buses that don't exist. >>> >>> >> Exactly. >> >> So we can either "infect" the whole device tree with kvm (or maybe a >> more generic accelerator structure that also deals with Xen) or we need >> to pull the reference inside the device's init function from some global >> service (kvm_get_state). >> > Note that this topic is still waiting for good suggestions, specifically > from those who believe in kvm_state references :). This is not only > blocking kvmstate merge but will affect KVM irqchips as well. > > It boils down to how we reasonably pass a kvm_state reference from > machine init code to a sysbus device. I'm probably biased, but I don't > see any way that does not work against the idea of confining access to > kvm_state or breaks device instantiation from the command line or a > config file. > A KVM device should sit on a KVM specific bus that hangs off of sysbus. It can get to kvm_state through that bus. That bus doesn't get instantiated through qdev so requiring a pointer argument should not be an issue. Regards, Anthony Liguori > Jan > >