On 09/16/2015 06:57 PM, Tamas K Lengyel wrote: > > > On Tue, Sep 15, 2015 at 5:19 AM, Razvan Cojocaru > <rcojoc...@bitdefender.com <mailto:rcojoc...@bitdefender.com>> wrote: > > A previous version of this patch dealing with support for skipping > the current instruction when a vm_event response requested it > computed the instruction length in the hypervisor, adding non-trivial > code dependencies. This patch allows a userspace vm_event client to > simply request that the guest's EIP is set to an arbitary value, > computed by the introspection application. > > > So in my opinion this patch introduces a feature that is not strictly > tied to emulation related vm_event paths. I could use this feature to > update the instruction pointer any time we respond to a vm_event and > furthermore, it may be benefitial to expand the scope of which registers > can be updated this way. For example, I have tools that update not just > the instruction pointer but also the stack pointer and registers used to > pass function inputs. Since we already send a snapshot of select > registers to the user with each event, we could introduce a response > flag that indicates that all registers included in that snapshot should > be set to the values sent back by the user. The user then could choose > which registers need to be updated in bulk. > > What do you think?
Hello Tamas, thanks for the reply! Yes, I thought it might come up that this doesn't have to be emulation-specific, but thought I'd hitch it there since I've assumed that at the moment this is the only case where it's actually used. I have nothing in principle against having a SET_REGISTERS flag instead of a SET_EIP one, but I am unsure of how (and where) that would be best implemented. What do you have in mind? A handler similar to void vm_event_register_write_resume() where we set these registers for the respective vcpu? Is this even possible at vm_event response handling time? Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
