A few days ago I posted some stuff about hooking an ISR without knowing what vector and DIRQL I should use. I’ve given up on that for the moment, as the hardware is on-board AMD processors, and AMD’s own driver to access this hardware seems to be relying on things within the HAL, which AMD probably had a hand in writing.
Meantime, I’m trying to service the hardware periodically using a Dpc associated with a periodic timer. That’s simple enough and the Dpc is getting called periodically.
The problem is that the Dpc is running on an arbitrary processor, but I want to use the MSRs on a specific processor, say processor 0. If the Dpc happens to be running on processor 1, then the RDMSR and WRMSR instruction get the MSRs for processor 1. But I need the MSRs for processor 0.
How do I do this??? Some ideas…
(1) find out how processor 1 can get to the MSRs for processor 0, through some sort of memory mapping, I suppose, as it can get to the APIC registers through a memory map. AMD’s processor programming guide doesn’t have anything that I could find on this subject.
(2) force the Dpc to always run on processor 0.
(3) some other way to cause a function to run on processor 0. Perhaps hook it as an ISR associated with some periodic timer events.
(4) run a higher-priority user thread on processor 0 that will wait for periodic timer events and then send an IOCTL to my driver, which will then work with the profiling hardware. It appears that DeviceIoControl always runs the driver’s dispatch routine in the same processor. (Is this actually true?)
I know I can do (4) if nothing else works. I’m hoping one of you will have a different solution.
I have the impression that the whole design of drivers is oriented around the driver code not having to care which processor it’s running on. Which is fine for system-wide devices or resources. But I’d like to think there’s a clean way that driver code can get to resources on a specific processor.