From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH] vm_event: Implement ARM SMC events Date: Wed, 13 Apr 2016 09:13:29 -0600 Message-ID: References: <1460404042-31179-1-git-send-email-tamas@tklengyel.com> <570CA910.8050404@bitdefender.com> <570D2135.1040204@arm.com> <570D2AC3.2040801@bitdefender.com> <570E0967.3070600@bitdefender.com> <570E1CD5.7000802@citrix.com> <570E2513.5060502@bitdefender.com> <570E3548.3040502@citrix.com> <0307D576-2907-4B35-BFC9-FAD67E340C07@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3182912565914534391==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqMTz-0007ms-LV for xen-devel@lists.xenproject.org; Wed, 13 Apr 2016 15:13:31 +0000 Received: by mail-wm0-f53.google.com with SMTP id a140so107465829wma.0 for ; Wed, 13 Apr 2016 08:13:29 -0700 (PDT) In-Reply-To: <0307D576-2907-4B35-BFC9-FAD67E340C07@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Lars Kurth Cc: Lars Kurth , Wei Liu , Razvan Cojocaru , Stefano Stabellini , Andrew Cooper , Ian Jackson , Julien Grall , Jan Beulich , Xen-devel , Keir Fraser , Corneliu ZUZU List-Id: xen-devel@lists.xenproject.org --===============3182912565914534391== Content-Type: multipart/alternative; boundary=047d7b86c8c063278c05305f3812 --047d7b86c8c063278c05305f3812 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 13, 2016 at 9:06 AM, Lars Kurth wrote: > > On 13 Apr 2016, at 14:25, Tamas K Lengyel > wrote: > > In the DRAKVUF system that's exactly what I do, I mark the page execute > only so that the guest is unable to locate/overwrite injected breakpoints > without notice. If it were to overwrite injected breakpoints with its own, > then we would be able to tell that the trap is both for external and > internal use. So there isn't much of an issue there. The main issue is with > the racecondition in multi-vCPU guests when the purely external-use > breakpoint has to be removed to allow the guest to continue. It can be > solved nicely though with altp2m. I did a write-up for the Xen blog about > it a couple months ago and sent it to publicity but has not appeared yet. > Lars? > > Tamas, > > it hasn't because I was under the impression that Razvan and you disagreed > on some aspects of the article. And then I forgot to chase either of you. I > am happy with the article: feel free to upload it to the blog (or let me > know, if I should) and press the button. Apologies > > I think there are a couple of minor knit-picks, such as replace "In the > latest release of Xen last summer several new features have been > introduced" In "Xen 4.6 several new features have been introduced" ... > assuming 4.6 is correct > > I will reply to publicity > > Regards > Lars > Hey Lars, I think the discussion with Razvan was mostly just around the difference of our perception of how emulation based solutions fare compared to altp2m. I think it's a discussion that actually could continue on the blogpost comment wall, or if Razvan feel like it in a follow-up blogpost ;) So feel free to make any changes to the article you see fit and hit release whenever you feel like. Thanks, Tamas --047d7b86c8c063278c05305f3812 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 13, 2016 at 9:06 AM, Lars Kurth <lars.kurth.xen@gma= il.com> wrote:

On 13 Apr 2016, at 14:25, Tamas K Lengyel <tamas.k.lengyel@gmail.com>= wrote:

In the DRAKVUF system that's exactly w= hat I do, I mark the page execute only so that the guest is unable to locat= e/overwrite injected breakpoints without notice. If it were to overwrite in= jected breakpoints with its own, then we would be able to tell that the tra= p is both for external and internal use. So there isn't much of an issu= e there. The main issue is with the racecondition in multi-vCPU guests when= the purely external-use breakpoint has to be removed to allow the guest to= continue. It can be solved nicely though with altp2m. I did a write-up for= the Xen blog about it a couple months ago and sent it to publicity but has= not appeared yet. Lars?

Tamas,

=
it hasn't because I was under the impression that Razvan and= you disagreed on some aspects of the article. And then I forgot to chase e= ither of you. I am happy with the article: feel free to upload it to the bl= og (or let me know, if I should) and press the button. Apologies
=
I think there are a couple of minor knit-picks, such as repl= ace "In the latest release of Xen last summer several new features hav= e been introduced" In "Xen 4.6 several new features have been int= roduced" ... assuming 4.6 is correct

I will r= eply to publicity

Regards
Lars

Hey Lars,
I think the discussion with Ra= zvan was mostly just around the difference of our perception of how emulati= on based solutions fare compared to altp2m. I think it's a discussion t= hat actually could continue on the blogpost comment wall, or if Razvan feel= like it in a follow-up blogpost ;) So feel free to make any changes to the= article you see fit and hit release whenever you feel like.

<= div>Thanks,
Tamas

--047d7b86c8c063278c05305f3812-- --===============3182912565914534391== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============3182912565914534391==--