[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






>> +Â Â Â Â Â Â 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.

Tamas

_______________________________________________
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®.