From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Cc: keir@xen.org, jbeulich@suse.com
Subject: Re: [PATCH] xen: Disable REP MOVSD optimization if introspection is active
Date: Mon, 27 Oct 2014 13:09:39 +0200 [thread overview]
Message-ID: <544E27F3.2080703@bitdefender.com> (raw)
In-Reply-To: <544E2383.1020604@citrix.com>
On 10/27/2014 12:50 PM, Andrew Cooper wrote:
> On 27/10/14 10:37, Razvan Cojocaru wrote:
>> REP MOVSD emulation is optimized to write several pages at once
>> if possible. While this is a very good thing in general, it
>> can interfere with a memory introspection application's ability
>> to detect suspect behaviour, since it supresses potentially
>> telling future page faults. This patch disables the optimization,
>> gated on introspection being active for the domain.
>
> An individual rep_movs() call should only optimise to within the current
> page, then break back out to the emulator when passing the page boundary.
>
> How does this suppress pagefaults?
You're right, sorry for the confusion. Indeed, although we do need (and
have tested) the patch, its description is misleading (and wrong, as
you've rigtly noticed).
Rep_movs() does indeed optimise within the current page, however the
introspection application looks at the EPT mem_event parameters in order
to decide what to do, and the problem is that for the optimized cases
only one mem_event is being sent (for the first MOV) with the initial
gpa and gla. Then no more events are being sent for the rest of the
operation in that page, which is confusing for a client application
expecting to be called for each actual write to a protected page.
If you feel that the patch is acceptable, I'll correct the description
when submitting V2.
Thanks,
Razvan
next prev parent reply other threads:[~2014-10-27 11:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 10:37 [PATCH] xen: Disable REP MOVSD optimization if introspection is active Razvan Cojocaru
2014-10-27 10:50 ` Andrew Cooper
2014-10-27 11:09 ` Razvan Cojocaru [this message]
2014-10-27 11:14 ` Andrew Cooper
2014-10-27 13:01 ` Jan Beulich
2014-10-27 13:33 ` Razvan Cojocaru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544E27F3.2080703@bitdefender.com \
--to=rcojocaru@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.