From: Avi Kivity <avi@redhat.com>
To: Andre Przywara <andre.przywara@amd.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] svm: implement NEXTRIPsave SVM feature
Date: Mon, 12 Apr 2010 13:20:36 +0300 [thread overview]
Message-ID: <4BC2F3F4.4030309@redhat.com> (raw)
In-Reply-To: <1271020048-10083-1-git-send-email-andre.przywara@amd.com>
On 04/12/2010 12:07 AM, Andre Przywara wrote:
> On SVM we set the instruction length of skipped instructions
> to hard-coded, well known values, which could be wrong when (bogus,
> but valid) prefixes (REX, segment override) are used.
> Newer AMD processors (Fam10h 45nm and better, aka. PhenomII or
> AthlonII) have an explicit NEXTRIP field in the VMCB containing the
> desired information.
> Since it is cheap to do so, we use this field to override the guessed
> value on newer processors.
> A fix for older CPUs would be rather expensive, as it would require
> to fetch and partially decode the instruction. As the problem is not
> a security issue and needs special, handcrafted code to trigger
> (no compiler will ever generate such code), I omit a fix for older
> CPUs.
> If someone is interested, I have both a patch for these CPUs as well as
> demo code triggering this issue: It segfaults under KVM, but runs
> perfectly on native Linux.
>
>
> @@ -319,6 +319,9 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
>
> + if (svm->vmcb->control.next_rip != 0)
> + svm->next_rip = svm->vmcb->control.next_rip;
> +
> if (!svm->next_rip) {
> if (emulate_instruction(vcpu, 0, 0, EMULTYPE_SKIP) !=
> EMULATE_DONE)
>
How does this interact with nested svm? Suppose we exit a nested guest,
then emulate a #VMEXIT, we'll have next_rip from a previous exit?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
next prev parent reply other threads:[~2010-04-12 10:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-11 21:07 [PATCH] svm: implement NEXTRIPsave SVM feature Andre Przywara
2010-04-11 21:40 ` Alexander Graf
2010-04-11 21:43 ` Alexander Graf
2010-04-11 21:51 ` Andre Przywara
2010-04-11 21:57 ` Alexander Graf
2010-04-11 22:13 ` Andre Przywara
2010-04-11 22:18 ` Alexander Graf
2010-04-12 10:20 ` Avi Kivity [this message]
2010-04-12 10:29 ` Alexander Graf
2010-04-12 10:34 ` Avi Kivity
2010-04-13 16:31 ` Marcelo Tosatti
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=4BC2F3F4.4030309@redhat.com \
--to=avi@redhat.com \
--cc=andre.przywara@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox