From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlTdA-0003a9-L3 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 16:19:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlTd5-0003YH-Uf for qemu-devel@nongnu.org; Wed, 09 Sep 2009 16:19:04 -0400 Received: from [199.232.76.173] (port=38621 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlTd5-0003Y8-MW for qemu-devel@nongnu.org; Wed, 09 Sep 2009 16:18:59 -0400 Received: from mail-qy0-f194.google.com ([209.85.221.194]:34423) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlTd5-00062b-CG for qemu-devel@nongnu.org; Wed, 09 Sep 2009 16:18:59 -0400 Received: by qyk32 with SMTP id 32so3850849qyk.19 for ; Wed, 09 Sep 2009 13:18:58 -0700 (PDT) Message-ID: <4AA80DAE.8030006@codemonkey.ws> Date: Wed, 09 Sep 2009 15:18:54 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration References: <20090909151111.26816.49862.stgit@mchn012c.ww002.siemens.net> <4AA7CC66.5060008@us.ibm.com> <4AA7D6AC.7090101@siemens.com> <4AA7ECF8.6040504@us.ibm.com> <4AA80970.90000@web.de> In-Reply-To: <4AA80970.90000@web.de> Content-Type: text/plain; charset=UTF-8; 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: Blue Swirl , Anthony Liguori , Dor Laor , Glauber Costa , qemu-devel@nongnu.org Jan Kiszka wrote: > Anthony Liguori wrote: > >> 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. >> > > Yes, QemuOpts is a must-have for -rtc. So you agree to introduce -rtc > (in addition to the qdev-based configuration, of course)? > Yup. >> 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. >> >> > > Moreover, quite a few (of not all?) other RTCs use the host time > already. Well, I would be happy to avoid that 'clock' knob. So if there > are no concerns, I will unconditionally switch MC146818 to host_clock. > Regards, Anthony Liguori