[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] xen: Introduce VM_EVENT_FLAG_SET_EIP


  • To: Jan Beulich <JBeulich@xxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Mon, 21 Sep 2015 12:05:26 +0300
  • Cc: "wei.liu2@xxxxxxxxxx" <wei.liu2@xxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Mon, 21 Sep 2015 09:03:21 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=cEzUwGfwt0+DfOqRBrIeMzc9Mion1+f/Meh1yVR3RM5rmcGPnCSLrh4OVPmAJAzScTUj3ld5Tbh9xo6OmDiFnk30H1vvHW6WotzKWRC23eBMdzGsYCrHVqo87RS+lUFC8AzBF5AFqMzskFccLbH9WKwTPphnctkp+sF2hIF1Kq1SoSe16vay5MYwZ4KZmb1O8wbNSIwR9qz504I2lCErwxsm12Gwy9NIufpGmwEhhlCfMy9uhA8QVKtkBEQeEkQoaRKNZVyp804sLfZQuOI0fGbFXCPz5hdK7rnS5WNjEd6gDua1FG3cLz3NYUhW+ZGOm2BILg7gNSD64jXG2Zj8yw==; h=Received:Received:Received:Received:Received:From:Subject:To:References:Cc:X-Enigmail-Draft-Status:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 09/21/2015 11:53 AM, Jan Beulich wrote:
>>>> On 18.09.15 at 21:19, <tamas@xxxxxxxxxxxxx> wrote:
>> On Wed, Sep 16, 2015 at 12:12 PM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx 
>>> wrote:
>>> 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.
> 
> I.e. I take this to mean that we should wait for a new patch
> rather than further looking at the current one.

Yes, I've already modified the first patch on Andrew Cooper's suggestion
(to switch from xc_domain_emulate_each_rep() to
xc_monitor_emulate_each_rep(), and gate the emulation disable condition
on mem_access_emulate_enable as well as mem_access_emulate_each_rep),
and I'm working on switching from SET_EIP to SET_REGISTERS as we speak,
after which I'll do a test run and send a new version, hopefully no
later than tomorrow.

For this patch, I'm slightly unsure if I should expect trouble for
trying to do it this way (I know I have to abstract that raw code away
for x86 and ARM in their respective functions, but let's just assume x86
for the example):

418         if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
419         {
420             if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
421                 v->arch.user_regs.eip = rsp.data.regs.x86.rip;
422
423             if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
424                 vm_event_toggle_singlestep(d, v);
425
426             vm_event_vcpu_unpause(v);
427         }

at the end of vm_event_resume() in common/vm_event.c. Looks like it
should be safe, but I'm not sure.


Thanks,
Razvan

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