[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1711201223070.1734@nanos>
Date: Mon, 20 Nov 2017 12:24:29 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Jan Kiszka <jan.kiszka@....de>
cc: Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>,
x86@...nel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
jailhouse-dev@...glegroups.com
Subject: Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping
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.
Thanks,
tglx
Powered by blists - more mailing lists