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
| ||
|
Date: Mon, 20 Nov 2017 13:21:25 +0100 From: Jan Kiszka <jan.kiszka@....de> To: Thomas Gleixner <tglx@...utronix.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 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
Powered by blists - more mailing lists