On Wed, Apr 13, 2016 at 9:06 AM, Lars Kurth <lars.kurth....@gmail.com> wrote:
> > On 13 Apr 2016, at 14:25, Tamas K Lengyel <tamas.k.leng...@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
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
