mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
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
Subject: Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping
Date: Mon, 20 Nov 2017 13:21:25 +0100	[thread overview]
Message-ID: <3ddc32e7-d1a0-445d-f820-985d89bbb16a@web.de> (raw)
In-Reply-To: <alpine.DEB.2.20.1711201223070.1734@nanos>

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.

Jan

  reply	other threads:[~2017-11-20 12:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16  7:26 [PATCH 00/10] x86: Add support for running as secondary Jailhouse guest Jan Kiszka
2017-11-16  7:26 ` [PATCH 01/10] x86/apic: Install an empty physflat_init_apic_ldr Jan Kiszka
2017-11-17 21:43   ` Thomas Gleixner
2017-11-16  7:26 ` [PATCH 02/10] x86: jailhouse: Add infrastructure for running in non-root cell Jan Kiszka
2017-11-17 21:54   ` Thomas Gleixner
2017-11-18 19:21     ` Jan Kiszka
2017-11-20 11:22       ` Thomas Gleixner
2017-11-16  7:26 ` [PATCH 03/10] x86: jailhouse: Enable APIC and SMP support Jan Kiszka
2017-11-17 22:42   ` Thomas Gleixner
2017-11-20 14:39     ` Konrad Rzeszutek Wilk
2017-11-20 17:26       ` Thomas Gleixner
2017-11-16  7:26 ` [PATCH 04/10] x86: jailhouse: Enable PMTIMER Jan Kiszka
2017-11-17 22:44   ` Thomas Gleixner
2017-11-16  7:26 ` [PATCH 05/10] x86: jailhouse: Set up timekeeping Jan Kiszka
2017-11-17 22:49   ` Thomas Gleixner
2017-11-18 19:23     ` Jan Kiszka
2017-11-20 11:24       ` Thomas Gleixner
2017-11-20 12:21         ` Jan Kiszka [this message]
2017-11-23 18:36           ` Thomas Gleixner
2017-11-23 19:48             ` Jan Kiszka
2017-11-16  7:26 ` [PATCH 06/10] x86: jailhouse: Avoid access of unsupported platform resources Jan Kiszka
2017-11-17 22:57   ` Thomas Gleixner
2017-11-17 22:59     ` Thomas Gleixner
2017-11-16  7:26 ` [PATCH 07/10] x86: jailhouse: Silence ACPI warning Jan Kiszka
2017-11-16  7:26 ` [PATCH 08/10] x86: jailhouse: Halt instead of failing to restart Jan Kiszka
2017-11-16  7:26 ` [PATCH 09/10] x86: jailhouse: Wire up IOAPIC for legacy UART ports Jan Kiszka
2017-11-17 23:14   ` Thomas Gleixner
2017-11-16  7:26 ` [PATCH 10/10] x86: jailhouse: Initialize PCI support Jan Kiszka
2017-11-18 21:15 ` [PATCH 00/10] x86: Add support for running as secondary Jailhouse guest H. Peter Anvin
2017-11-20  7:00   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ddc32e7-d1a0-445d-f820-985d89bbb16a@web.de \
    --to=jan.kiszka@web.de \
    --cc=hpa@zytor.com \
    --cc=jailhouse-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®