All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: Alexander Graf <agraf@suse.de>
Cc: Avi Kivity <avi@redhat.com>, kvm-devel list <kvm@vger.kernel.org>
Subject: Re: [PATCH] svm: implement NEXTRIPsave SVM feature
Date: Mon, 12 Apr 2010 00:13:06 +0200	[thread overview]
Message-ID: <4BC24972.3070301@amd.com> (raw)
In-Reply-To: <9837F692-5DB6-4E81-9CFD-8405312DE542@suse.de>

Alexander Graf wrote:
> On 11.04.2010, at 23:51, Andre Przywara wrote:
> 
>> Alexander Graf wrote:
>>> On 11.04.2010, at 23:40, Alexander Graf wrote:
>>>> /* Either adds offset n to the instruction counter or takes the next
>>>>   instruction pointer from the vmcb if the CPU supports it */
>>>>
>>>> static u64 svm_next_rip(struct kvm_vcpu *vcpu, int add)
>>>> {
>>>>       if (svm->vmcb->control.next_rip != 0)
>>> In fact, that if should probably be:
>>>        if (svm_has(SVM_FEATURE_NRIP))
>> This is not sufficient. The next RIP is only provided for some
 >> intercepts (namely instruction intercepts), so one would need to
 >> check the validity of this field anyway. By definition reserved
>> VMCB fields are 0, and as 0 is never a valid _next_ RIP, this
 >> is a quick and correct check.
> It's not? If you're at -1 which is hlt in our imaginary case. What would the next instruction be?
A wrap-around to zero? From kernel space to user space? Come on, that 
sounds a bit constructed (A20, someone?). I dimly remember reading in 
our internal docs that 0 is a safe indicator for a missing NEXTRIP. I 
will do some research tomorrow.

>> P.S. I don't have a strong opinion about your proposed refactoring,
>> if Avi agrees I will rework it. I only found the current fix small
>> and easy, and the mentioned patch for older CPUs removed the add
 >> line anyway, so the concerns you rose did not apply to the original
>> version of the patch.
> 
> What patch for older CPUs? The one that'd be expensive?
Yes. It removes the "guessed" value lines entirely and triggers a decode 
if NEXTRIP is not available.
 > I was more concerned about readability here - it's great to
 > be able to follow code on what it does :-).
Maybe a comment about the overriding behavior of the NEXTRIP line would 
appease you?

Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 488-3567-12


  reply	other threads:[~2010-04-11 22:14 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 [this message]
2010-04-11 22:18           ` Alexander Graf
2010-04-12 10:20 ` Avi Kivity
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=4BC24972.3070301@amd.com \
    --to=andre.przywara@amd.com \
    --cc=agraf@suse.de \
    --cc=avi@redhat.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.