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: Thu, 30 May 2019 12:39:33 +0000 From: Michael Kelley <mikelley@...rosoft.com> To: vkuznets <vkuznets@...hat.com> CC: "catalin.marinas@....com" <catalin.marinas@....com>, "mark.rutland@....com" <mark.rutland@....com>, "will.deacon@....com" <will.deacon@....com>, "marc.zyngier@....com" <marc.zyngier@....com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>, "olaf@...fle.de" <olaf@...fle.de>, "apw@...onical.com" <apw@...onical.com>, "jasowang@...hat.com" <jasowang@...hat.com>, "marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>, Sunil Muthuswamy <sunilmut@...rosoft.com>, KY Srinivasan <kys@...rosoft.com> Subject: RE: [PATCH v3 2/2] Drivers: hv: Move Hyper-V clocksource code to new clocksource driver From: Vitaly Kuznetsov <vkuznets@...hat.com> Sent: Thursday, May 30, 2019 2:48 AM > > + /* > > + * sched_clock_register is needed on ARM64 but > > + * is a no-op on x86 > > + */ > > + sched_clock_register(read_hv_sched_clock_msr, > > + 64, HV_CLOCK_HZ); > > I'm not sure about ARM, but MSR-based clocksource would be a really bad > choice for sched clock on x86, this will slow things down > significantly. Luckily, as you're validly stating above, > sched_clock_register() is a no-op on x86 as we don't define > CONFIG_GENERIC_SCHED_CLOCK. > > Can we actually *not* do sched_clock_register() in case > TSC page is unavailable (and revert to counting jiffies or whatever)? > We can't skip the sched_clock_register() on ARM64 because it does define CONFIG_GENERIC_SCHED_CLOCK. However, Hyper-V should always provide REFERENCE_TSC_AVAILALBE on ARM64, so we should never end up in the MSR-based code on ARM64. Arguably that means the call to sched_clock_register() could be removed since it's a no-op on x86. But I'd like to keep it for symmetry and in case there's a testing/debugging situation on ARM64 where we want to clear REFERENCE_TSC_AVAILABLE and go down the MSR-based code path. Michael
Powered by blists - more mailing lists