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

RE: [Xen-ia64-devel] [PATCH] This is the second patch to merge vcpu.c


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
  • From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • Date: Tue, 20 Sep 2005 10:17:39 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 20 Sep 2005 02:15:13 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcW9EOnsq8f7PkrtRbOf9CBoPVTbywACNUQgABsm3zA=
  • Thread-topic: [Xen-ia64-devel] [PATCH] This is the second patch to merge vcpu.c

>The patch looks good except one possible caution worth
>thinking about: the change to the definition of vcpu_regs.
>If vcpu_regs is used when the stack is "nested"

I was also thinking about this issue, but the vcpu_regs is used to
access guest state( first level pt_regs), in nested situation, VMM
should not use vcpu_regs to access pt_regs(which is guest state), VMM
should only access the nested pt_regs( maybe the second( or third) level
pt_regs under first level pt_regs), Am I right?


>Assuming the "old" way of obtaining regs is no
>longer necessary, the patch should probably remove
>vcpu_set_regs, the call to vcpu_set_regs in
>privop.c, the use of arch.regs in process.c,
>and the element regs from the arch data structure.
>We can remove those in a followup patch.

Agree!
We should remove vcpu_set_regs and element regs.
And we should also remove ia64_prepare_handle_privop,
ia64_prepare_handle_break, ia64_prepare_handle_reflection, which are
never used.
I'll do this in next patch.



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

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