All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.