[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.