|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Behaviour when setting CPU_BASED_MONITOR_TRAP_FLAG in hvm_do_resume()
On 03/07/2016 03:13 PM, Andrew Cooper wrote:
> On 06/03/16 13:35, Razvan Cojocaru wrote:
>> Hello,
>>
>> Assuming I set v->arch.hvm_vmx.exec_control |=
>> CPU_BASED_MONITOR_TRAP_FLAG; in hvm_do_resume(), would that cause a
>> VMEXIT with EXIT_REASON_MONITOR_TRAP_FLAG _before_ the instruction at he
>> current rIP runs, or _after_ it?
>>
>> A few tests I've ran suggest that the VMEXIT occurs _before_, i.e. the
>> instruction is not running between setting the flag and the VMEXIT, but
>> the actual code is a bit more involved and I might have just come across
>> a corner case, so I thought it would be best to have official
>> confirmation on the list.
>
> Wow the SDM is opaque in its description of the monitor trap flag.
>
> My reading of section 25.5.2 is that you will get a MTF exit on every
> new instruction boundary, other than the rip pending at the vmentry,
> which would give it fault semantics.
>
> In the case of interacting with interrupts or traps, the trap/interrupt
> action will occur before the MTF exit, and the exit will be on the
> boundary starting the exception handler.
>
>
> This would make it consistent with the other intercept semantics, where
> even interception of software traps behave like faults. (e.g. c/s 0747bc8)
The issue turned out to be that if _only_ the MTF is set but not
v->arch.hvm_vcpu.single_step, vmx_intr_assist() doesn't return early:
221 void vmx_intr_assist(void)
222 {
223 struct hvm_intack intack;
224 struct vcpu *v = current;
225 unsigned int tpr_threshold = 0;
226 enum hvm_intblk intblk;
227 int pt_vector = -1;
228
229 /* Block event injection when single step with MTF. */
230 if ( unlikely(v->arch.hvm_vcpu.single_step) )
231 {
232 v->arch.hvm_vmx.exec_control |= CPU_BASED_MONITOR_TRAP_FLAG;
233 vmx_update_cpu_exec_control(v);
234 return;
235 }
i.e. even if MTF is already set, only v->arch.hvm_vcpu.single_step counts.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |