From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: xen-devel@lists.xen.org
Cc: "Lengyel, Tamas" <tlengyel@novetta.com>
Subject: Failed vm entry when emulating in hvm_do_resume()
Date: Mon, 4 Apr 2016 16:32:11 +0300 [thread overview]
Message-ID: <57026CDB.4090504@bitdefender.com> (raw)
Hello,
As a test, I've modified xen-access.c to this simplified skeleton:
http://pastebin.com/48WYwW00
then started up an x86 Windows 7 HVM guest, and ran it with:
# ./xen-access <dom_id> write
once the login screen appeared. The guest promptly crashed with this
backtrace:
http://pastebin.com/Bz0GeFta
The modified xen-access.c simply removes write rights for all of the
guest's pages, then attempts to emulate all instructions that might
cause a page fault. While I didn't expect the guest to run in a useable
manner, or Xen to be able to emulate all the instructions, I did not
expect the guest to crash.
So it would seem that hvm_do_resume() is, after all, not the best place
to emulate after a vm_event reply asks for emulation.
It's also not clear if (since in entry.S vmx_intr_assist() is being
called very early) we might not be, instead of right where we left off
on the VPCU when we sent out the mem_access vm_event, in an interrupt
handler (where emulating the first instruction is not good).
Could someone please recommend a safe place to try to emulate if
hvm_do_resume() is problematic?
Should I go back to the comparably inefficient way we did it before
(emulate on the second page fault where the RIP and GPA match)?
That indeed seems to offer no surprise crashes, but has the
aforementioned efficiency drawback, coupled with the fact that an
interrupt can cause the EIP and GPA to differ, in which case it would
take 4 page faults to finally emulate an offending instruction and
proceed. I did try the previous access_check() solution, and in addition
returning from vmx_intr_assist() (like the single stepping code does) if
there's an emulation request pending:
222 void vmx_intr_assist(void)
223 {
224 struct hvm_intack intack;
225 struct vcpu *v = current;
226 unsigned int tpr_threshold = 0;
227 enum hvm_intblk intblk;
228 int pt_vector = -1;
229
230 /* Block event injection when an instruction emulation is
pending. */
231 if ( unlikely(v->arch.vm_event) && v->arch.vm_event->emulate_flags )
232 return;
However that seems to trigger occassional BSODs related to clock
interrupts: http://i.imgur.com/EEz3JBV.png
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2016-04-04 13:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 13:32 Razvan Cojocaru [this message]
2016-04-04 14:43 ` Failed vm entry when emulating in hvm_do_resume() 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=57026CDB.4090504@bitdefender.com \
--to=rcojocaru@bitdefender.com \
--cc=tlengyel@novetta.com \
--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.