Are you trying to get NMI IRETs? or generic IRETs?
I think SVM has a specific IRET control bit (but obviously, based on
your question, you are on an Intel chip).
If I'm reading the manual right, Paolo's suggestion should work. That
said, I have some hacky suggestions that won't get you every IRET and
will take more work.
1: Enable interrupt window exits whenever you inject an interrupt. It
won't work every time (you won't get irets from nested interrupts, or
if the guest clears IF), but you should get pretty much every other
one.
2: If you want to do a lot of work, you could set the GDT limit to 0
and enable GP exiting whenever you inject an interrupt (I think you'll
also have to disable posted-interrupts). You'll have to keep count of
how many interrupts you've nested so you know when you are resuming a
normal non-interrupt context. And make sure your GPs aren't normal
GPs.
On Fri, Feb 24, 2017 at 12:20 PM, sci sci <scicomplete@xxxxxxxxx> wrote:
> Thanks very much for the reply.
>
> I set all the four that you mentioned and am still having trouble with
> intecepting guest IRET.
>
> I print out the following right before the assembly instructions for
> entering guest in vmx_vcpu_run() function in vmx.c file.
>
> "vmcs config pin based 3f cpu based b6e0edfa cpu based2 fb interruptibility 8"
>
> The printf statement producing this is :
> printk(KERN_ERR " vmcs config pin based %x cpu based %x cpu based2 %x
> interruptibility %x\n", vmcs_config.pin_based_exec_ctrl,
> vmcs_config.cpu_based_exec_ctrl,
> vmcs_config.cpu_based_2nd_exec_ctrl,vmcs_read32(GUEST_INTERRUPTIBILITY_INFO));
>
> You can see that I am setting all four bits that you mentioned.
>
> I am testing for vmexits due to IRET in the vmx_handle_exit()
> function with the following test:
>
> // this check is from Section 31.7.1.2 of the intel manual
> "Resuming Guest Software after Handling an Exception"
> if( ((vectoring_info & 2147483648) == 0) && ((vectoring_info &
> 255)!=8) && ((vectoring_info & 4096)==1) ){
> printk(KERN_ERR "kvm nmi blocking exit complex check caught
> using hw interception due to IRET \n");
> }
>
> if( exit_reason == EXIT_REASON_NMI_WINDOW ){
> printk(KERN_ERR "kvm nmi window exit simple exit reason caught
> using hw interception due to IRET \n");
> }
>
> Within the guest I run a BSD guest OS that returns from certain system
> calls using the IRET instruction.
>
>
> Do you have any thoughts on where I could be wrong?
>
>
> Thanks !
>
>
> On Fri, Feb 24, 2017 at 6:40 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>>
>>
>> On 24/02/2017 11:32, sci sci wrote:
>>> I tried several combinations of the following settings but with little
>>> success.
>>>
>>> 1) Set/Unset Virtual NMIs which is bit 5 in pin based vm execution control
>>> 2) Set/Unset bit 3 in guest interruptibility state (Blocking by NMI)
>>> 3) Set/Unset "NMI-blocking" which is bit 3 in pin based NMI exiting
>>> 4) Set/Unset "NMI-window exiting" which is bit 22 in primary processor
>>> based VM execution control.
>>
>> Doing all four of these should do it:
>>
>> - set bit 3 in pin-based controls to cause a VMEXIT for host NMIs and
>> enable special processing of IRET (paragraph 25.3)
>>
>> - set bit 5 in pin-based controls so that guest interruptibility state
>> tracks virtual-NMI blocking
>>
>> - set bit 22 of VM executino control to enable the NMI-window vmexit
>>
>> - set bit 3 in guest interruptibility state to delay the NMI-window exit
>> until the next IRET
>>
>> Paolo
