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 > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53094 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfF3Z-00073r-OE for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:09:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfF3K-0004Wm-Kv for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:09:21 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:51547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfF3K-0004WF-FH for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:09:06 -0500 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0IGswvc011113 for ; Tue, 18 Jan 2011 09:54:58 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0IH93Sn159588 for ; Tue, 18 Jan 2011 10:09:03 -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 p0IH93sc003337 for ; Tue, 18 Jan 2011 10:09:03 -0700 Message-ID: <4D35C92D.7030000@linux.vnet.ibm.com> Date: Tue, 18 Jan 2011 11:09:01 -0600 From: Anthony Liguori 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> <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> In-Reply-To: <4D35C648.7050809@siemens.com> 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: "kvm@vger.kernel.org" , Glauber Costa , Marcelo Tosatti , "qemu-devel@nongnu.org" , Markus Armbruster , Avi Kivity 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 > >