From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlQHc-0002rs-66 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:44:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlQHX-0002pn-G2 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:44:35 -0400 Received: from [199.232.76.173] (port=51543 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlQHX-0002pi-6c for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:44:31 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24557) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MlQHW-0000HB-3f for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:44:31 -0400 Message-ID: <4AA7DAA8.6030403@siemens.com> Date: Wed, 09 Sep 2009 18:41:12 +0200 From: Jan Kiszka 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 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: Anthony Liguori Cc: Blue Swirl , Glauber Costa , Dor Laor , qemu-devel@nongnu.org Jan Kiszka wrote: > Anthony Liguori wrote: >> Jan Kiszka wrote: >>> The aim of this series is to allow using the emulated PC RTC (MC146818) >>> as a reliable time source for guests. This is particularly useful if the >>> host runs NTP or has otherwise access to an accurate clock while the >>> guest has not (no network, impossible to add an NTP implementation >>> etc.). >>> >>> To achieve this, the command line switch -rtc is introduced. It takes >>> the option 'clock' to switch between the currently used base ('vm') and >>> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to >>> deprecate all the other RTC-related stand-alone switches. >>> >>> First tests indicate that this approach works as expected and could >>> increase the usefulness of the virtual RTC enormously. However, there >>> might be pitfalls I've missed so far. Feedback would be welcome! >>> >> 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. Or is the policy > now to freeze all command line switches in favor of the -device and > -set?. However, I will look into qdev conversion of the PC RTC. Thinking further: Is there a way to discover the available qdev device parameters via the command line? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux