Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Journeyman III

AMD-V (SVM) intercept software interrupt, how to get vector number?

AMD-V (SVM) intercept software interrupt, how to get vector number?

I was able to intercept int n by setting up the SINT flag.

But my question is how to know the value of n (vector number)?

The manual does not tell how to do it. I tested by creating a custom int x and searched for x  in VMCB and visible registers after #VMEXIT but could not find it.

I guess I could try to fetch the opcode from guest cs:ip, but then I have to write code to handle guest segmentation and paging, which is tedious. And I couldnot think of any reason why AMD does not give the vector number to the VMM after a software interrupt interception. Hope someone knows the answer.



5 Replies

The current implementation does not provide n.  Unless you’re emulating a BIOS, it’s unlikely that you actually need to intercept software interrupts.  I’m curious; why are you intercepting them?


Hi devcentral,

I am so glad someone finally answered. It seems that not many people are working on SVM technology right now.

I want to intercept sytem calls in the guest OS. Somehow the 2.6 Linux distros I am testing all use interrupt 0x80 for this (tty Linux for example).

I was able to get the vector number, by walking through guest segmentation and paging. Then I tried to insert the same software interrupt to the guest, using event injection mechanism described in AMD manual vol 2, SVM chapter. The guest behaves a bit differently, and much much more slower. All the registers are the same with or without the interception when I do so but it still be able to boot up and give me the shell command line. I am trying to find the root cause of the difference.



If you want to implement your own BIOS outside the guest, a better solution would be to put a stub BIOS into the guest, and fill each BIOS call with a VMMCALL instruction.  Then you’ll get a quick, well-known call to the hypervisor on each guest BIOS call.  You’re definitely better off not intercepting #PF, since those occur very frequently.

I’d also suggest you look at how KVM or Xen emulate BIOS.

(This suggestion applies to your other post as well, so I've duplicated this response there.)


I want to intercept guest OS's system calls (such as read(),open()...), not exactly BIOS call. And one of my goal is to not modify the guest OS

I am looking at KVM at the moment.

Thanks a lot for your help.


We suggest that you use an in-guest OS profiler.  There are many such profilers available, such as strace.


Hope this helps.