lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 23 Nov 2017 19:36:39 +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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ