From: "Mihai Donțu" <mdontu@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andrei LUTAS <vlutas@bitdefender.com>,
xen-devel@lists.xensource.com, keir@xen.org, jbeulich@suse.com
Subject: xen: generic instruction re-execution mechanism for execute faults
Date: Tue, 9 Sep 2014 06:01:11 +0300 [thread overview]
Message-ID: <20140909060111.0d888575@bitdefender.com> (raw)
Hi,
This is another patch from which we stepped back for a while in order
to give it a better thought:
http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg00309.html
Our argument for it is that memory introspection technologies can cause
a VMEXIT practically at any point during the guest execution, even
without any 'malicious' activity going on in it. If the instruction
that caused the exit is well within a protected page, we would need to:
a) emulate it
b) single step it
The emulation part would be the desired option, but unfortunately it
requires a full blown emulator which I believe is beyond the scope of
Xen. One would rather have to somehow tap into qemu (if at all
possible).
The other option, which is permanent in that it does not need to be
maintained like an emulator, is to suspend all vCPU's, grant
permissions to the fault page, single step the guest, return to Xen and
then resume. It has a bit of overhead, but the fact that this code path
is seldom taken and cumulated with the efficiency of latest hardware
makes it the better choice. Also, the tests we have conducted show no
observable slowdown.
In conclusion: is there any way we can bring this idea (either in the
proposed form by the patch or any other) into Xen?
Thanks,
--
Mihai Donțu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2014-09-09 3:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 3:01 Mihai Donțu [this message]
2014-09-09 8:35 ` xen: generic instruction re-execution mechanism for execute faults Andrew Cooper
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=20140909060111.0d888575@bitdefender.com \
--to=mdontu@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=vlutas@bitdefender.com \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).