From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments Date: Tue, 11 Jan 2011 09:55:56 -0600 Message-ID: <4D2C7D8C.8070503@linux.vnet.ibm.com> References: <4D2616D6.4080309@linux.vnet.ibm.com> <4D26D6CF.5070405@web.de> <4D27A16F.9030809@linux.vnet.ibm.com> <4D282489.90506@web.de> <4D2B6506.6070907@linux.vnet.ibm.com> <4D2B6845.7050809@web.de> <4D2B6ADD.4090505@codemonkey.ws> <4D2C1C5D.2050504@redhat.com> <4D2C6290.1060607@linux.vnet.ibm.com> <1EA102F5-B6C2-43BC-9493-0271B287FC18@suse.de> <4D2C649F.6080508@linux.vnet.ibm.com> <4D2C67C2.5080000@redhat.com> <4D2C6AFA.4040104@linux.vnet.ibm.com> <4D2C6FAB.3050209@redhat.com> <4D2C7353.2000008@linux.vnet.ibm.com> <4D2C793C.2070003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:49877 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756185Ab1AKP5H (ORCPT ); Tue, 11 Jan 2011 10:57:07 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BFkxxi019532 for ; Tue, 11 Jan 2011 08:46:59 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0BFulqM164462 for ; Tue, 11 Jan 2011 08:56:54 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0BG1DJQ018666 for ; Tue, 11 Jan 2011 09:01:14 -0700 In-Reply-To: <4D2C793C.2070003@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/11/2011 09:37 AM, Avi Kivity wrote: >>> Why not? Whatever state the kernel keeps, we expose to userspace >>> and allow sending it over the wire. >> >> What exactly is the scenario you're concerned about? >> >> Migration between userspace HPET and in-kernel HPET? > > Yes. To a lesser extent, a client doing 'info hpet' or similar and > failing for kernel hpet. That's pretty easy to address. >> >> One thing I've been considering is essentially migration filters. It >> would be a set of rules that essentially were "hpet-kvm.* = hpet.*" >> which would allow migration from hpet to hpet-kvm given a translation >> of state. I think this sort of higher level ruleset would make it >> easier to support migration between versions of the device model. >> >> Of course, that only gives you a forward path. It doesn't give you a >> backwards path. >> > > It would be easier to have them use the same device id in the first > place. > > If it looks like an i8254, quacks like an i8254, and live migrates > like an i8254, it's probably an i8254. And that's fine. I'm not suggesting you call it i8253. But it's two separate implementations. We should make that visible, not try to hide it. It's an important detail. Imagine getting a sosreport that includes a dump of the device tree. You really want to see something in there that tells you it's an in-kernel PIT and not the userspace one. Regards, Anthony Liguori From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58894 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pcgar-0004PO-8Y for qemu-devel@nongnu.org; Tue, 11 Jan 2011 10:57:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pcgap-0004DL-Q5 for qemu-devel@nongnu.org; Tue, 11 Jan 2011 10:57:09 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:54623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pcgap-0004Bv-Kl for qemu-devel@nongnu.org; Tue, 11 Jan 2011 10:57:07 -0500 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BFokVC002423 for ; Tue, 11 Jan 2011 08:50:46 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0BFulRi166190 for ; Tue, 11 Jan 2011 08:56:47 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0BG1DJK018666 for ; Tue, 11 Jan 2011 09:01:13 -0700 Message-ID: <4D2C7D8C.8070503@linux.vnet.ibm.com> Date: Tue, 11 Jan 2011 09:55:56 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments References: <4D2616D6.4080309@linux.vnet.ibm.com> <4D26D6CF.5070405@web.de> <4D27A16F.9030809@linux.vnet.ibm.com> <4D282489.90506@web.de> <4D2B6506.6070907@linux.vnet.ibm.com> <4D2B6845.7050809@web.de> <4D2B6ADD.4090505@codemonkey.ws> <4D2C1C5D.2050504@redhat.com> <4D2C6290.1060607@linux.vnet.ibm.com> <1EA102F5-B6C2-43BC-9493-0271B287FC18@suse.de> <4D2C649F.6080508@linux.vnet.ibm.com> <4D2C67C2.5080000@redhat.com> <4D2C6AFA.4040104@linux.vnet.ibm.com> <4D2C6FAB.3050209@redhat.com> <4D2C7353.2000008@linux.vnet.ibm.com> <4D2C793C.2070003@redhat.com> In-Reply-To: <4D2C793C.2070003@redhat.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: Avi Kivity Cc: Marcelo Tosatti , Jan Kiszka , Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org On 01/11/2011 09:37 AM, Avi Kivity wrote: >>> Why not? Whatever state the kernel keeps, we expose to userspace >>> and allow sending it over the wire. >> >> What exactly is the scenario you're concerned about? >> >> Migration between userspace HPET and in-kernel HPET? > > Yes. To a lesser extent, a client doing 'info hpet' or similar and > failing for kernel hpet. That's pretty easy to address. >> >> One thing I've been considering is essentially migration filters. It >> would be a set of rules that essentially were "hpet-kvm.* = hpet.*" >> which would allow migration from hpet to hpet-kvm given a translation >> of state. I think this sort of higher level ruleset would make it >> easier to support migration between versions of the device model. >> >> Of course, that only gives you a forward path. It doesn't give you a >> backwards path. >> > > It would be easier to have them use the same device id in the first > place. > > If it looks like an i8254, quacks like an i8254, and live migrates > like an i8254, it's probably an i8254. And that's fine. I'm not suggesting you call it i8253. But it's two separate implementations. We should make that visible, not try to hide it. It's an important detail. Imagine getting a sosreport that includes a dump of the device tree. You really want to see something in there that tells you it's an in-kernel PIT and not the userspace one. Regards, Anthony Liguori