Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
        x86@kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        jailhouse-dev@googlegroups.com
References: <cover.1510817211.git.jan.kiszka@siemens.com>
 <62f3fde8db44e5aedf934b5a753d448979f50082.1510817211.git.jan.kiszka@siemens.com>
 <alpine.DEB.2.20.1711172345220.2186@nanos>
 <12f18935-51a5-08a1-bf72-42e3367a2f87@web.de>
 <alpine.DEB.2.20.1711201223070.1734@nanos>
 <3ddc32e7-d1a0-445d-f820-985d89bbb16a@web.de>
 <alpine.DEB.2.20.1711231936090.2364@nanos>
From:   Jan Kiszka <jan.kiszka@web.de>
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: <alpine.DEB.2.20.1711231936090.2364@nanos>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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

From 1584883046916165337@xxx Thu Nov 23 18:37:36 +0000 2017
X-GM-THRID: 1584208245671673621
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread