From: Nadav Har'El <nyh@math.technion.ac.il>
To: Gleb Natapov <gleb@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [PATCH] KVM: nVMX: Rework event injection and recovery
Date: Thu, 21 Feb 2013 15:28:51 +0200 [thread overview]
Message-ID: <20130221132851.GA8847@fermat.math.technion.ac.il> (raw)
In-Reply-To: <20130221131332.GA14354@redhat.com>
On Thu, Feb 21, 2013, Gleb Natapov wrote about "Re: [PATCH] KVM: nVMX: Rework event injection and recovery":
> will not be called while there is an event to reinject. 51cfe38ea5 still
> does not explain why nested_run_pending is needed. We cannot #vmexit
> without entering L2, but we can undo VMLAUNCH/VMRESUME emulation leaving
> rip pointing to the instruction. We can start by moving
> skip_emulated_instruction() from nested_vmx_run() to nested_vmx_vmexit().
This is a very interesting idea!
Don't forget to also skip_emulated_instruction() in nested_vmx_entry_failure().
And please expand the comment at the end of nested_vmx_run(), saying
that also skipping the instruction is done on exit, unless the
instruction needs to be retried because we needed to inject an
interrupt into L1 before running it.
Whether this is actually clearer than the "nested_run_pending" approach
I don't know.
--
Nadav Har'El | Thursday, Feb 21 2013, 11 Adar 5773
nyh@math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Cat rule #2: Bite the hand that won't
http://nadav.harel.org.il |feed you fast enough.
next prev parent reply other threads:[~2013-02-21 13:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 13:01 [PATCH] KVM: nVMX: Rework event injection and recovery Jan Kiszka
2013-02-20 14:14 ` Nadav Har'El
2013-02-20 14:37 ` Jan Kiszka
2013-02-20 17:01 ` Gleb Natapov
2013-02-20 17:24 ` Jan Kiszka
2013-02-20 17:50 ` Jan Kiszka
2013-02-21 9:22 ` Gleb Natapov
2013-02-21 9:43 ` Jan Kiszka
2013-02-21 10:06 ` Gleb Natapov
2013-02-21 10:18 ` Jan Kiszka
2013-02-21 10:28 ` Jan Kiszka
2013-02-21 10:33 ` Jan Kiszka
2013-02-21 13:13 ` Gleb Natapov
2013-02-21 13:22 ` Jan Kiszka
2013-02-21 13:37 ` Nadav Har'El
2013-02-21 13:45 ` Gleb Natapov
2013-02-21 13:28 ` Nadav Har'El [this message]
2013-02-20 14:53 ` Jan Kiszka
2013-02-20 15:30 ` Gleb Natapov
2013-02-20 15:51 ` Jan Kiszka
2013-02-20 15:57 ` Gleb Natapov
2013-02-20 16:00 ` Jan Kiszka
2013-02-20 16:46 ` Gleb Natapov
2013-02-20 16:48 ` Jan Kiszka
2013-02-20 16:51 ` Gleb Natapov
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=20130221132851.GA8847@fermat.math.technion.ac.il \
--to=nyh@math.technion.ac.il \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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