weird semantics of cpu/*/msr

weird semantics of cpu/*/msr

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

hi :)

the i386 msr driver is a bit strange:

* when reading/writing, it does not update the file position/msr register
* file position is used directly as msr register

that is, reads with count>8 do read from the same register multiple
times, and writes overwrite themselves.

i would expect the following semantics:
* file position is (msr register * 8). position%8!=0 is invalid
* read/write updating file position.

that would make it possible to write/read multiple MSRs with one
syscall, which is very handy when initializing P4 performance counters.

should i implement that behaviour?
of course it would break binary compatibility with existing
uses of that drivers.
perhaps we would need a new location for the new api.

comments?

-- 
CU,		  / Friedrich-Alexander University Erlangen, Germany
Martin Waitz	//  [Tali on IRCnet]  [tali.home.pages.de] _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet    //
tippfehler und ist auch ohne grossbuchstaben gueltig.   /
			    -
Wer bereit ist, grundlegende Freiheiten aufzugeben, um sich 
kurzfristige Sicherheit zu verschaffen, der hat weder Freiheit 
noch Sicherheit verdient.
			Benjamin Franklin  (1706 - 1790)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: weird semantics of cpu/*/msr

[H. Peter Anvin]

Martin Waitz wrote:
> hi :)
> 
> the i386 msr driver is a bit strange:
> 
> * when reading/writing, it does not update the file position/msr register
> * file position is used directly as msr register
> 
> that is, reads with count>8 do read from the same register multiple
> times, and writes overwrite themselves.
> 
> i would expect the following semantics:
> * file position is (msr register * 8). position%8!=0 is invalid
> * read/write updating file position.
> 
> that would make it possible to write/read multiple MSRs with one
> syscall, which is very handy when initializing P4 performance counters.
> 
> should i implement that behaviour?
> of course it would break binary compatibility with existing
> uses of that drivers.
> perhaps we would need a new location for the new api.
> 

No, you should not.

Simply put, the semantics were chosen for what typically makes sense
w.r.t. MSRs.

	-hpa