linux-kernel - Re: [PATCH] Skip tsc synchronization checks if CONSTANT

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:	Wed, 22 Oct 2008 19:21:18 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Daniel Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Skip tsc synchronization checks if CONSTANT_TSC bit is
	set.

On Wed, 2008-10-22 at 15:54 -0700, Andi Kleen wrote:
> > Not really, there are problems with the pm timer too, the one about
> > missing the counter wrap and time dropping in chunks of 4 seconds.
> > Tried to explain it over here, http://lkml.org/lkml/2008/10/22/525
> 
> Well then pit. 

PIT is not available as a clocksource if highres or one-shot timers are
enabled. So PIT is not a possibility. 

> 
> Or are you saying time is always broken on VMware & Linux?

The acpi_pm timer wrap problem has come up only with the clocksource and
NO_HZ kernels, without NO_HZ there were periodic interrupts which caused
the guest to be scheduled before ACPI_PM could wrap around.

> > So TSC is the ideal clocksource from performance and correctness point
> > of view for VMware.
> 
> But you don't seem to emulate it "ideal"ly otherwise you wouldn't
> need all these hacks you're adding?

"All these hacks" ? i guess you are talking about only this particular,
skipping the tsc_sync checks.
Rest of them are valid bugs as i have mentioned.

> 
> I think you should either implement a TSC that matches what
> real hardware does (including CPUID semantics) 

Yeah accepted, i agree this is the right approach and that's the long
term view that we are taking too.

> or implement
> a real vmware PV timer and just say it's PV and not fully virtualized.
> But doesn't the vmware paravirt ops have that already anyways?

That's for 32bit only. Apart from the tsc_sync problem i doubt we have
any other issue with the TSC as clocksource, so adding a similar
clocksource is something that i would avoid.

> 
> But I personally think it wouldn't really scale to add detection for
> more and more "nearly PV" hypervisors to the standard native kernel.

I think we anyways need a way to detect if we are running on a
hypervisor. That's the only way we can move towards having a single
image which runs well on both native hardware and a virtualized
environment. 

I guess, the only thing that you don't agree over here is the enabling
of CONSTANT_TSC bit when VMware is detected, right ?
I would agree that this could be viewed as a hack but that is the only
way we can have the kernel still working correctly on the already
released platforms. And, this should be viewed no different than the
case of fixing a slightly different behavior of a particular hardware. 

Thanks,
Alok

> 
> -Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/