From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlRSM-0003l5-Iq for qemu-devel@nongnu.org; Wed, 09 Sep 2009 13:59:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlRSF-0003gy-CQ for qemu-devel@nongnu.org; Wed, 09 Sep 2009 13:59:43 -0400 Received: from [199.232.76.173] (port=54521 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlRSF-0003ge-08 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 13:59:39 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:32952) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MlRSE-0006qw-28 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 13:59:38 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n89Ht3M5007372 for ; Wed, 9 Sep 2009 11:55:03 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n89HxM7i177348 for ; Wed, 9 Sep 2009 11:59:30 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n89HxM32025851 for ; Wed, 9 Sep 2009 11:59:22 -0600 Message-ID: <4AA7ECF8.6040504@us.ibm.com> Date: Wed, 09 Sep 2009 12:59:20 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20090909151111.26816.49862.stgit@mchn012c.ww002.siemens.net> <4AA7CC66.5060008@us.ibm.com> <4AA7D6AC.7090101@siemens.com> In-Reply-To: <4AA7D6AC.7090101@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , Glauber Costa , Dor Laor , qemu-devel@nongnu.org Jan Kiszka wrote: > Anthony Liguori wrote: > >> You get most of this pretty cheaply with qdev conversion. If you give >> the rtc a default id, you can tweak all of the properties with the -set >> command line option. It also provides a mechanism to change the default >> properties between machine types/versions which is ideal as we can >> introduce a kvm-specific machine type where we enable some of these >> things by default. >> >> > > Hmm, the refactoring of the old command line switches to -rtc is, if I > understand qdev and -set correctly, widely orthogonal. No, it isn't. To introduce -rtc properly, you should use QemuOpts. We shouldn't be introducing new options that don't conform to QemuOpts syntax and the best way to do that is to just use QemuOpts. To communicate the QemuOpts to the rtc, I think the easiest approach is to convert rtc to qdev and reuse the -device logic. Otherwise, you have to use statics or add new parameters to the machine init. > Or is the policy > now to freeze all command line switches in favor of the -device and > -set?. As much as possible, yes, I think this is the reasonable thing to do. > However, I will look into qdev conversion of the PC RTC. > > Besides the interface thing, I'm also interesting in comments on the > other core idea, the selectable RTC base clock. Do we want this knob? Do > we want host_clock unconditionally? Or should the other RTC that > currently use the host time already also gain vm_clock support over the > time? > Hard to say. Doesn't the rtc keep track of wallclock time even on power off? I think using host_clock unconditionally does actually make sense. -- Regards, Anthony Liguori