Thanks, Tim and Anton.
The short story is that, apparently, the CodeXL driver does not use interrupts from the IBS hardware at all, hence no interrupt vector is involved. Rather, it uses a timer interrupt to periodically poll the IBS to see if a sample is available.
Regarding help from AMD community, there is a DevGurus forum, but there’s very little activity on it. They have a CodeXL subforum which hasn’t had any activity since 4 months ago. The general discussions subforum is more active. I’m going to join the forum and post my question and see. Also, there’s a general email for AMD support that I’ll try. If I learn anything I’ll post it here.
I was mistaken about using vector number 1. I thought that the value was being stored in a word that would later go into the LVT, but I had the wrong base register in the disassembly. So I still don’t know where the driver is getting the vector number.
Since there is no call to IoConnectInterrupt(Ex), I am going to assume the driver is using a repeating timer interrupt. In fact, the function that checks the IBS hardware for a rollover and reads the info MSRs and reenables the sampling is called Deferred_TimerInterrupt
Service, and looks like it is scheduled by KeInitializeTimer.
I’m guessing also that where the driver sets the IBS’ LVT entry, it is doing so to disable the interrupt, rather than enable it and store a vector. The IBS hardware always signals an interrupt when a sample is taken, and the LVT determines whether the processor is actually interrupted.