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

Re: [Xen-devel] svm: save_svm_cpu_user_regs vs. svm_store_cpu_guest_regs

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 09 May 2007 08:51:12 +0100
  • Delivery-date: Wed, 09 May 2007 00:47:52 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceSDs/8DmrOYv4CEdu9MQAWy6hiGQ==
  • Thread-topic: [Xen-devel] svm: save_svm_cpu_user_regs vs. svm_store_cpu_guest_regs

On 9/5/07 08:25, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> What is the reason for save_svm_cpu_user_regs() explicitly saving rax?
> Without this, the function could be eliminated, with its single use replaced
> by a call to svm_store_cpu_guest_regs().

It would be great if we can get away with just moving save/restore of rAX
into svm_{load,store}_cpu_guest_regs(), kill save_svm_cpu_user_regs()
completely, and get rid of the call at the top of the vmexit handler.
There's no equivalent call at the top of the VMX vmexit handler: all the
common HVM code will explicitly svm_store_cpu_guest_regs() before depending
on GPR state.

Or, if the loads/stores to/from the VMCB are really cheap we could simplify
things by always restoring from 'struct reg' on vmentry, always loading to
'struct reg' on vmexit (as the SVM code already does right now), and then
svm_{load,save}_cpu_guest_regs() become no-ops.

We should pick one or the other - lazy or eager - and stick with it.

 -- Keir

Xen-devel mailing list



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