On Wed, Apr 13, 2016 at 9:06 AM, Lars Kurth <lars.kurth.xen@gmail.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 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