From: Thomas Gleixner <tglx@linutronix.de>
To: Jan Kiszka <jan.kiszka@web.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: Thu, 23 Nov 2017 19:36:39 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1711231936090.2364@nanos> (raw)
In-Reply-To: <3ddc32e7-d1a0-445d-f820-985d89bbb16a@web.de>
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.
Thanks,
tglx
next prev parent reply other threads:[~2017-11-23 18:36 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
2017-11-23 18:36 ` Thomas Gleixner [this message]
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=alpine.DEB.2.20.1711231936090.2364@nanos \
--to=tglx@linutronix.de \
--cc=hpa@zytor.com \
--cc=jailhouse-dev@googlegroups.com \
--cc=jan.kiszka@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--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®