[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] NextRIPS support for forthcoming AMD processors

  • To: Mark Langsdorf <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Wed, 15 Oct 2008 22:11:18 +0100
  • Cc:
  • Delivery-date: Wed, 15 Oct 2008 14:11:35 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckvCpCpz0n8Npr9Ed2JPwAWy6hiGQ==
  • Thread-topic: [Xen-devel] [PATCH] NextRIPS support for forthcoming AMD processors

On 15/10/08 22:03, "Mark Langsdorf" <mark.langsdorf@xxxxxxx> wrote:

> Future versions of AMD processors will support a feature called
> NextRIPS or Next RIP Save.  This feature causes the processor
> to store the next sequential RIP of a guest in the VMCB on
> most instruction interrupts.  The hypervisor can use this
> information to determine how much memory to read to determine
> the intercepted instruction, modestly improving performance.
> The following patch implements support for this feature.
> This patch has been stress tested at AMD for three weeks of
> continuous runtime and should not cause any regressions.

Why bother with a 'nrip' boot parameter? If this feature works, let's always
enable it. The check of vmexit code in svm_nextrip_is_valid() could also
perhaps be avoided? _get_instruction_length[_from_list]() is used only in a
very few cases, and in quite likely all those situations the nrip field
would actually be valid. Have you checked that, or are there in fact some
callers for whom nrip isn't guaranteed valid?

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.