(Wait, that first suggestion doesn't make any sense. Somehow forgot
interrupt window exiting isn't blocked by other interrupts.)
On Fri, Feb 24, 2017 at 1:21 PM, Steve Rutherford
<srutherford@xxxxxxxxxx> wrote:
> 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
