From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlQ1M-0006iN-8D for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:27:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlQ1H-0006gu-Ec for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:27:47 -0400 Received: from [199.232.76.173] (port=33779 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlQ1H-0006go-3f for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:27:43 -0400 Received: from david.siemens.de ([192.35.17.14]:17714) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MlQ1G-000621-Gy for qemu-devel@nongnu.org; Wed, 09 Sep 2009 12:27:42 -0400 Message-ID: <4AA7D6AC.7090101@siemens.com> Date: Wed, 09 Sep 2009 18:24:12 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090909151111.26816.49862.stgit@mchn012c.ww002.siemens.net> <4AA7CC66.5060008@us.ibm.com> In-Reply-To: <4AA7CC66.5060008@us.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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. 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? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux