From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnBje-0005Bh-Ch for qemu-devel@nongnu.org; Mon, 14 Sep 2009 09:36:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnBjZ-00058C-DV for qemu-devel@nongnu.org; Mon, 14 Sep 2009 09:36:49 -0400 Received: from [199.232.76.173] (port=56250 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnBjZ-00057y-8o for qemu-devel@nongnu.org; Mon, 14 Sep 2009 09:36:45 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:40801) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MnBjY-0000v1-Km for qemu-devel@nongnu.org; Mon, 14 Sep 2009 09:36:44 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8EDf7nS032052 for ; Mon, 14 Sep 2009 09:41:07 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8EDaZVm1556726 for ; Mon, 14 Sep 2009 09:36:36 -0400 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 n8EDaXLP020437 for ; Mon, 14 Sep 2009 07:36:35 -0600 Message-ID: <4AAE46DF.5070205@us.ibm.com> Date: Mon, 14 Sep 2009 08:36:31 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20090909222333.GA19385@shareable.org> <4AAA1059.9060505@siemens.com> <4AAD0B09.8040903@redhat.com> <4AAD119F.2000107@web.de> In-Reply-To: <4AAD119F.2000107@web.de> Content-Type: text/plain; charset=ISO-8859-1; 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 , dlaor@redhat.com, "qemu-devel@nongnu.org" Jan Kiszka wrote: > Dor Laor wrote: > >> I'm in favor of sticking to clock=vm as a default. >> Most chances that the guest will have internet connect and the host (ala >> rom hypervisor) won't have. >> Default behaviors only really matter for unmanaged environments. An isolated hypervisor in a rom is most certainly a managed environment. As long as there is the ability to do clock=vm, setting clock=host by default should be fine. > Except for Jamie's case of extending some license runtime, I really see > no real use for RTC based on vm_clock anymore. There is some reason why > other RTCs are already based on the host clock. > In general, behaving like real hardware by default and supporting odd use-cases with additional options seems like a good policy to me. > Jan > -- Regards, Anthony Liguori