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

Re: [Xen-devel] [PATCH V6 5/5] xen: Handle resumed instruction based on previous mem_event reply


  • To: George Dunlap <dunlapg@xxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Wed, 10 Sep 2014 19:12:35 +0300
  • Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Wed, 10 Sep 2014 16:12:37 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=B+ncPhbGAc3y6330fsQxxbZItJ1Gak9J7TlvVxgW0n+11ey+CcUYJmkq3tH0s8c/crNnrgd8CYCY7fKrnAHIGBr+vmoAKA6ucpXC/KEqAOMjJvEt/tMmba5pkGoeEXEsBnigvxTG6I0cZPJfjsrHYPQhkXDzmkHDLLivEbFXlF8CsAB+6W3Z4p+EzKfPn81AFvW8mZ7IFflwt4jum7F7jNxn6UHw4ZKoTVB0i6tDOX4jaGEq/Eji+8flXFHHknOBiw72mfLw6OZnBIe55mMZ6RebO1MLDDO5mV7zWLgFtMiEQSy7XyczaZ2qzM1+sQXP2D4+PScSehoIdpvtDdE8bg==; h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References: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/10/2014 07:03 PM, George Dunlap wrote:
> On Tue, Sep 9, 2014 at 11:28 AM, Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> In a scenario where a page fault that triggered a mem_event occured,
>> p2m_mem_access_check() will now be able to either 1) emulate the
>> current instruction, or 2) emulate it, but don't allow it to perform
>> any writes.
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> [snip]
> 
>> +    else if ( v->arch.mem_event.emulate_flags == 0 &&
>> +              npfec.kind != npfec_kind_with_gla ) /* don't send a mem_event 
>> */
>> +    {
>> +        v->arch.mem_event.emulate_flags = MEM_EVENT_FLAG_EMULATE;
>> +        v->arch.mem_event.gpa = gpa;
>> +        v->arch.mem_event.eip = eip;
>> +    }
> 
> It looks like the previous if() is true, that it will never get to
> this point (because it will either return 0 or 1 depending on whether
> p2m->access_required is set).  So you don't need to make this an
> "else" here -- you should just add a blank line and make this a normal
> if().
> 
> Also, maybe it's just because I'm not familiar with the mem_event
> interface, but I don't really see what this code is doing.  It seems
> to be changing the behavior even for clients that aren't using
> MEM_EVENT_FLAG_EMULATE*.  Is that intended?  In any case it seems like
> there could be a better comment here.

Thanks, those are very good points. I'll make that a regular if(), and
test also if introspection monitoring is enabled (please see patch 3/5:
d->arch.hvm_domain.introspection_enabled) before setting the emulate
flag, that way we won't alter the behaviour for other clients.

As for the previous if, I think that if it holds then it won't be
possible to send a mem_event anyway, hence the else.


Thanks,
Razvan Cojocaru

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