Best strategy for tracking interrupts?

Best strategy for tracking interrupts?

After discussing how to track software interrupts with
colleagues there appears to be two methods to achieve tracking of interrupts.
My first thought is to have the user process call handler invoke an
unregistered interrupt, trap the 0xB vmexit and then inject an event (software
interrupt) which handles the call.
I am trying to inject a software interrupt into our guest 0x82. However,I
modify the vmcs.VM_ENTRY_INTR_INFO = (1<< 31) | (0 << 11) |
(4<< 8) | 0x82;
I then restart the vm and nothing happens. Currently 0x82 just invokes
vmcall as a sanity check to see if it is working.

The other option I'm thinking about is to mark the page of the IDT handler as
not present in the ept pages and when it page faults, see what's faulting, mark the page as
present and resume. It would mean more exits though.

1) Am I injecting the event incorrectly? I have read over sections
24.8.3, and 26.5 multiple times.
2) Would the second method be easier and/or more correct?

3) Is there a new processor coming with controllable software interrupt exit's
similar to AMD?


2 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

Just to follow up, I was was not committing edits to the vmcs. However, now it causes a triple faults when it actually does deliver the interrupt. How do I clear the fault in the guest and clear the way to deliver the new interrupt?

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi