Re: [Xen-devel] [SVM] Getting the length of the current instruction in svm_vmexit_handler()

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 03/17/2018 11:45 PM, Andrew Cooper wrote:
> On 17/03/18 21:11, Razvan Cojocaru wrote:
>> On 03/14/2018 07:06 PM, Andrew Cooper wrote:
>>> On 14/03/18 15:53, Jan Beulich wrote:
>>>>>>> On 14.03.18 at 15:56, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>> We'd like to retrieve the length of the current instruction in
>>>>> svm_vmexit_handler(), specifically for the VMEXIT_EXCEPTION_DB and
>>>>> VMEXIT_EXCEPTION_BP cases.
>>>>>
>>>>> We've combed the vmcb to no avail. Everything we've thought to check
>>>>> (exitinfo1, exitinfo2, exitintinfo) turns out to be zero there while
>>>>> testing.
>>>>>
>>>>> There's __get_instruction_length(vcpu, instr), but it expects to be fed
>>>>> the exact instruction we want the length for, which obviously defeats
>>>>> the purpose here.
>>>>>
>>>>> Is there a clean way to get the current instruction length like we do in
>>>>> the VMX case (__vmread(VM_EXIT_INSTRUCTION_LEN, &insn_len)) that we're
>>>>> overlooking?
>>>> Just like Intel's, AMD's is available in a subset of cases only
>>>> (look for vmcb->guest_ins_len), which don't include the
>>>> exception intercepts you talk about. For #DB I think there's
>>>> no difference between both anyway.
>>> On non-first-gen hardware, the difference between RIP and NextRIP should
>>> give you the instruction length.  ISTR NextRIP is written on all exits,
>>> and consumed on all entries.
>> Thanks!
>>
>> vmcb->nextrip - vmcb->rip seems to work well for the instruction length.
> 
> Turns out I was wrong.
> 
>>From 15.7.1 "State Saved on Exit":
>> The next sequential instruction pointer (nRIP) is saved in the guest
>> VMCB control area at location C8h
>> on all #VMEXITs that are due to instruction intercepts, as defined in
>> Section 15.9 on page 461, as well
>> as MSR and IOIO intercepts and exceptions caused by the INT3, INTO,
>> and BOUND instructions. For
>> all other intercepts, nRIP is reset to zero.

Still, it does work well for int3, int $3, into and icebp - so for
everything the swint XTF test throws at Xen.

> On 17/03/18 21:11, Razvan Cojocaru wrote:
>>
>> Shouldn't vmcb->exitintinfo also be filled in properly on SVM? I'm
>> getting this on VMEXIT_EXCEPTION_BP:
> 
> No.  The manual says not.  From 15.12.4 "#BP (Breakpoint)":
> 
>> This intercept applies to the trap raised by the single byte INT3
>> (opcode CCh) instruction. The
>> EXITINFO1 and EXITINFO2 fields are undefined. The CS:rIP reported on
>> #VMEXIT are those of
>> the INT3 instruction.

Fair enough, thanks!

> What other information are you trying to derive when intercepting #BP?

Well, we've added GENERAL2_INTERCEPT_ICEBP to the SVM intercepts, and
added a case VMEXIT_ICEBP: that's really just a fallthrough for case
VMEXIT_EXCEPTION_DB:, to try to make it look like what VMX currently
does (where icebp causes a debug vm_event). So now we'd like to call
hvm_monitor_debug(regs->rip, HVM_MONITOR_DEBUG_EXCEPTION, trap_type,
inst_len), where trap_type now needs to be
X86_EVENTTYPE_PRI_SW_EXCEPTION (5) for icebp, but whatever else is
appropriate for VMEXIT_EXCEPTION_DB. All this is made easy on VMX by
checking intr, but requires a lot of verbosity on SVM.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel