From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753301AbdKWTto (ORCPT ); Thu, 23 Nov 2017 14:49:44 -0500 Received: from mout.web.de ([212.227.15.4]:55008 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753229AbdKWTtn (ORCPT ); Thu, 23 Nov 2017 14:49:43 -0500 Subject: Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping To: Thomas Gleixner Cc: Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, Linux Kernel Mailing List , jailhouse-dev@googlegroups.com References: <62f3fde8db44e5aedf934b5a753d448979f50082.1510817211.git.jan.kiszka@siemens.com> <12f18935-51a5-08a1-bf72-42e3367a2f87@web.de> <3ddc32e7-d1a0-445d-f820-985d89bbb16a@web.de> From: Jan Kiszka Message-ID: <58881917-e17e-5fec-27c7-f2eb620750fa@web.de> Date: Thu, 23 Nov 2017 20:48:35 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CXc6r0mq3McapZa0ZOfaHg0xE9py2u4umOjwl+6BgyzoXRByKla 0exsd+NXBHPngjJa3FfeElWxUrvWSAfKTUWwxdVOfJ5oSLQujNamNRsbB86HPBpTvWvw0BD WsoxiDnqgNKk+LKIPmPxplTCDqVVvIoHC8BUaGmLuHD1L9Uk/7A4oTNvCdIi7ktg675F9JU anuOQcsbHP/E4gVQYrmSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:EHQmZFj3VVU=:MAyucAa5SXLbDjJ1t0NXaT uR7em4OA9Ue+Avcg09pbaqStF1+ps6kMO0nP0SYhcb8qEokZt5Df3U3mJx/FvgA3Pf3XB1jyU Z+oPs+XBnDBRk5W8O3tmDMU9wj0FoJDWo2b5x1/XmRiJ/CqgPZ4DV9pZRKxs3SmWvxSSO5fUg PMxBfAnxQoyY/wxEdmXeWmr7gYsw9+QHOCu/v/XCSa4p9nsEKP1u3TZgAWgKB1dDTjpDdILNm Movi7urfuR6yUvrqenraA0G1KrZjr1VoqHuXMUUtHSayWXri8UzjNe4n6D11NI+oXMO8r6Gya pRHL8jVQ9Df5pA/YZgtVM6zRM/2EjCOGGbIYDNcyuWvA7+Wc2gLQLwaqz/zXGOi1rCEK3/jh+ dwuL3So6gG5GUYG4RrI0sRmMqYcQuhJEHYe1Wo9wjZXSkOqxiomMYIqy/M2yFfBMtc5uZIiqd z3IaTTEuR7ZOVd4K0XceNgm9f+gReJ5yheYz5bIrMycIvmXd9RJSpgskZ81vhRsuYFB7Ue2zD 0508EFjwM7EuRIr5fHb4bI9zPpDQlZm4xtWMvQrfQX+QP+W248vYUd1m9qsbdclXYGUESI2/a RkAMuB3b2IcpDYgz/4nXm0ttClOdozRSp7rRBjOBSfWsEnt1JwAQV08QiYty/W8RfnOszhMXl 3OOFsNhYK9kZ2BwjFzjGSxBVY0F3TJ25UmxX/q+VNrWs/mGWngmpFiHmiPYN9NA9a8BlKNL5b 2p+RKlH5aNzkOY9XgUeZN2RwcWTpIAMLeCiOYIFLPjAXAEiIWHypqu/VPXqOpVHKYgh4bJsU0 zIrHCIHNz6AsWWQsStHoAFQRYYsk6pjxyqkCGgHOj9uLYb9fE8= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-11-23 19:36, Thomas Gleixner wrote: > On Mon, 20 Nov 2017, Jan Kiszka wrote: >> On 2017-11-20 12:24, Thomas Gleixner wrote: >>> On Sat, 18 Nov 2017, Jan Kiszka wrote: >>>> On 2017-11-17 23:49, Thomas Gleixner wrote: >>>>> On Thu, 16 Nov 2017, Jan Kiszka wrote: >>>>>> Calibrate the TSC and, where necessary, the APIC timer against the >>>>>> TMTIMER. We need our own implementation as neither the PIC nor the HPET >>>>>> are available, and the standard calibration routines try to make use of >>>>>> them. >>>>> >>>>> Why is this needed at all? >>>>> >>>>> The host the frequency already. So this can be done w/o pmtimer and extra >>>>> calibration routine. >>>> >>>> The hypervisor does not have the frequencies. It will never use the APIC >>>> timer (it's owned by the guests), and it has no use case for the TSC so >>>> far. Only the root cell (the Linux that booted the system) has that >>>> data. Now we could >>>> >>>> - trust the root cell to provide the right values and export them during >>>> startup to the hypervisor and from there to the non-root cells. >>>> >>>> - calculate the frequencies once and store them in the hyperivsor >>>> config, just like other system-specific information, for re-export to >>>> the cells. >>>> >>>> But I don't think option 1 will be ok for all use cases. Maybe a >>>> combination of both, falling back to the root cell data if nothing is >>>> defined in the config. Let me think about this. >>> >>> Another question is whether systems which can support jailhouse, have the >>> frequencies available via cpuid/msr and can avoid that calibration thing >>> completely. >> >> OK, some may (not Xeons, though), and we would not exploit it with this >> approach. > > Ok. Let's expose pmtimer it's not a big issue. I think PM timer should to be exposed independently of the question wheather calibrate or not. If - for whatever reason - TSC is/becomes unstable, we should have a fallback clock. I've started to hack on forwarding calibration results from (primary) Linux to the other guests with the option to alternatively hard-code the values in the configuration. Seems to work find, just requires to export lapic_timer_frequency. I'll push updates the next days that exploit this and simplifies this patch. Jan