On Wed, Sep 16, 2015 at 12:12 PM, Razvan Cojocaru <rcojoc...@bitdefender.com > wrote:
> 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? > No, that function falls under a switch on rsp.reason, for which we have a 1:1 unofficial and not really enforced rule to match the type of event that was sent. This should fall under a flag on rsp.flags and be handled similar to how vm_event_toggle_singlestep is. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
