All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nakajima, Jun" <jun.nakajima@intel.com>
To: "Alexandru Duţu" <alex.dutu@gmail.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: KVM exit on UD interception
Date: Mon, 5 May 2014 10:34:25 -0700	[thread overview]
Message-ID: <CAL54oT2w=2iaXJwbtKc3fAVfeqT0iopduC=XBSTzyrSwjL-rfg@mail.gmail.com> (raw)
In-Reply-To: <CAEKRH4EYZApPFw6P7xociS7npxzMFgzppv7Ay9k92=ihhf+U-Q@mail.gmail.com>

On Mon, May 5, 2014 at 8:56 AM, Alexandru Duţu <alex.dutu@gmail.com> wrote:
> Dear all,
>
> It seems that currently, on UD interception KVM does not exit
> completely. Virtualized execution finishes, KVM executes
> ud_intercept() after which it enters virtualized execution again.

Maybe you might want to take a look at the VMX side (to port it to
SVM). The MOVBE emulation, for example, should be helpful.

>
> I am working on accelerating with virtualized execution a simulator
> that emulates system calls. Essentially doing virtualized execution
> without a OS kernel. In order to make this work, I had to modify my
> the KVM kernel module such that ud_intercept() return 0 and not 1
> which break KVM __vcpu_run loop. This is necessary as I need to trap
> syscall instructions, exit virtualized execution with UD exception,
> emulate the system call in the simulator and after the system call is
> done enter back in virtualized mode and start execution with the help
> of KVM.
>
> So by modifying ud_intercept() to return 0, I got all this to work. Is
> it possible to achieve the same effect (exit on undefined opcode)
> without modifying ud_intercept()?
>
> It seems that re-entering virtualized execution on UD interception
> gives the user the flexibility of running binaries with newer
> instructions on older hardware, if kvm is able to emulate the newer
> instructions. I do not fully understand the details of this scenario,
> is there such a scenario or is it likely that ud_interception() will
> change?
>
> Thank you in advance!
>
> Best regards,
> Alex
> --

-- 
Jun
Intel Open Source Technology Center

  reply	other threads:[~2014-05-05 17:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05 15:56 KVM exit on UD interception Alexandru Duţu
2014-05-05 17:34 ` Nakajima, Jun [this message]
2014-05-05 18:48   ` Alexandru Duţu
2014-05-06  0:07     ` Nakajima, Jun
2014-05-06  0:47       ` Alexandru Duţu
2014-05-06 16:56 ` Paolo Bonzini
2014-05-06 20:11   ` Alexandru Duţu
2014-05-07  6:55     ` Paolo Bonzini
2014-05-08  3:30       ` Alexandru Duţu

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='CAL54oT2w=2iaXJwbtKc3fAVfeqT0iopduC=XBSTzyrSwjL-rfg@mail.gmail.com' \
    --to=jun.nakajima@intel.com \
    --cc=alex.dutu@gmail.com \
    --cc=kvm@vger.kernel.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.