I added safe (exception table guarded) MSR read/write APIs.
On Mon, Nov 23, 2015 at 8:23 PM, Davide Libenzi <[email protected]> wrote: > On Mon, Nov 23, 2015 at 3:27 PM, ron minnich <[email protected]> wrote: > >> Looking at how linux does it, it's >> /dev/cpu/#/msr, and you do reads/writes at offset for the msr. Further, >> the offset is interpreted: a true byte offset into the "MSR address space" >> would shift the msr # left 3 bits, since each MSR is 8 bytes, but they just >> do the same thing we all do, and just use the offset as an offset into "msr >> space", e.g. reading msr 58 it does a pread at offset 58, and you get eight >> bytes. >> >> So to read all the msrs you have a pread per core :-(. But if we had an >> iov call that let us specify offset per iov then we could have a gather of >> all the msrs in the kernel that we want for all cores in one vector read, >> and we could even do crazy stuff like read multiple msrs per core for some >> set of cores into an array ... I have a strange attraction for >> scatter/gather IO. I.e. you could do this: >> d0 = open("/dev/cpu/0/msr" ...) >> d1 = open("/dev/cpu/1/msr" ...) >> vread({d0, &buf[0], 16, 3a}, {d1, &buf[16], 16, 3a}) to read 3a and 3b in >> cores 0 and 1 >> > > I am not in love in populating N cpus namespace for MSR. > We could use: > > PREAD_PWRITE_OFFSET = MSR_ADDRESS | (CORE << 32) > > As pread/write offset. > But keep in mind that the MSR device will not be used by userspace perf, > for the reasons I outlined (and waiting for comments) in a separate email. > > > > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
