[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V3 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS
>>> On 28.09.15 at 20:46, <tamas@xxxxxxxxxxxxx> wrote: >> > + if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS ) >> >> + vm_event_set_registers(v, &rsp); >> >> + >> >> if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP ) >> >> vm_event_toggle_singlestep(d, v); >> > >> > What meaning has setting both flags and EFLAGS.TF in the new >> > register values? >> >> That's a good question. I'm not sure how that would affect an attached >> debugger type scenario. >> >> I'm also unsure of what a good solution to this issue would be. I could >> make the flags exclusive, but that would prevent, for example, setting >> EAX and singlestepping, which should not be a problem. I could also >> remove the eflags assignment from vm_event_set_registers() (maybe >> replace it with a comment). >> >> Tamas, do you need eflags set? What do you think? Again, I'm happy with >> just setting EIP, what scenarios are you interested in? >> >> > Being able to set registers this way and enabling MTF in one-shot I think > offers good flexibility and performance for vm_event applications. I don't > see any reason why these options should be exclusive. Furthermore, I don't > see why we would treat EFLAGS.TF any different then the others. If the > vm_event application decides to flip both the in-guest TF and the external > MTF, why prevent that? While I don't see an immediate use-case for this, I > also don't see why it would be problematic either. Okay. Sounds like an ack then - if so, could you formalize that? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |