linux-kernel - Re: Use of barriers in pvclock ABI

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:	Mon, 11 Aug 2008 11:18:58 -0300
From:	"Glauber Costa" <glommer@...il.com>
To:	"Gerd Hoffmann" <kraxel@...hat.com>
Cc:	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Avi Kivity" <avi@...ranet.com>,
	"Marcelo Tosatti" <mtosatti@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	kvm-devel <kvm-devel@...ts.sourceforge.net>
Subject: Re: Use of barriers in pvclock ABI

On Mon, Aug 11, 2008 at 4:08 AM, Gerd Hoffmann <kraxel@...hat.com> wrote:
>  Hi,
>
>> However, the pvclock_clocksource_read() implementation is
>> over-engineered, because it checks for an odd version and uses very
>> strong rmb() barriers (which generates either an "lfence" or "lock add
>> $0, (%esp)").
>>
>> If we're happy to guarantee as an ABI issue that the record will never
>> be updated cross-cpu, then we can make the barriers simply barrier() and
>> just check for (src->version != dst->version).
>>
>> Is that OK with you, or do you want to leave open the possibility of
>> doing cross-cpu time updates?
>
> Due to the TSC being involved here I don't expect cross-cpu time updates
> will ever happen.  IMHO it is fine to change that.

Okay for guest vcpu, but what about physical cpus?

IIRC, the checks are there, and so strict, to account for the
possiblity of the vcpu to be migrated to another cpu in the middle of
the
clock reading.
>
> cheers,
>  Gerd
>
> --
> http://kraxel.fedorapeople.org/xenner/
>



-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."
--
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/