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 11:09:01 -0600 Message-ID: <4D35C92D.7030000@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> <4D35ABF8.9050700@linux.vnet.ibm.com> <4D35B521.3090601@siemens.com> <4D35B6DD.1020005@linux.vnet.ibm.com> <4D35B963.7000605@siemens.com> <4D35BA22.7060602@linux.vnet.ibm.com> <4D35BD30.1060900@siemens.com> <4D35C1CE.10509@linux.vnet.ibm.com> <4D35C648.7050809@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 e31.co.us.ibm.com ([32.97.110.149]:54774 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752856Ab1ARRJS (ORCPT ); Tue, 18 Jan 2011 12:09:18 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0IGswHZ017177 for ; Tue, 18 Jan 2011 09:54:58 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0IH94Oq083066 for ; Tue, 18 Jan 2011 10:09:05 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0IH93si003337 for ; Tue, 18 Jan 2011 10:09:04 -0700 In-Reply-To: <4D35C648.7050809@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/18/2011 10:56 AM, Jan Kiszka wrote: > >> The device model topology is 100% a hidden architectural detail. >> > This is true for the sysbus, it is obviously not the case for PCI and > similarly discoverable buses. There we have a guest-explorable topology > that is currently equivalent to the the qdev layout. > But we also don't do PCI passthrough so we really haven't even explored how that maps in qdev. I don't know if qemu-kvm has attempted to qdev-ify it. >>> Management and analysis tools must be able to traverse the system buses >>> and find guest devices this way. >>> >> We need to provide a compatible interface to the guest. If you agree >> with my above statements, then you'll also agree that we can do this >> without keeping the device model topology stable. >> >> But we also need to provide a compatible interface to management tools. >> Exposing the device model topology as a compatible interface >> artificially limits us. It's far better to provide higher level >> supported interfaces to give us the flexibility to change the device >> model as we need to. >> > How do you want to change qdev to keep the guest and management tool > view stable while branching off kvm sub-buses? The qdev device model is not a stable interface. I think that's been clear from the very beginning. > Please propose such > extensions so that they can be discussed. IIUC, that would be second > relation between qdev and qbus instances besides the physical topology. > What further use cases (besides passing kvm_state around) do you have in > mind? > The -device interface is a stable interface. Right now, you don't specify any type of identifier of the pci bus when you create a PCI device. It's implied in the interface. > >> >>> If they create a device on bus X, it >>> must never end up on bus Y just because it happens to be KVM-assisted or >>> has some other property. >>> >> Nope. This is exactly what should happen. >> >> 90% of the devices in the device model are not created by management >> tools. They're part of a chipset. The chipset has well defined >> extension points and we provide management interfaces to create devices >> on those extension points. That is, interfaces to create PCI devices. >> >> > Creating kvm irqchips via the management tool would be one simple way > (not the only one, though) to enable/disable kvm assistance for those > devices. > It's automatically created as part of the CPUs or as part of the chipset. How to enable/disable kvm assistance is a property of the CPU and/or chipset. Regards, Anthony Liguori > Jan > >