WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] svm vmexit action sequence

To: "Mats Petersson" <Mats.Petersson@xxxxxxx>
Subject: RE: [Xen-devel] svm vmexit action sequence
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 11 May 2007 09:42:53 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 11 May 2007 00:40:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Sorry, yet another question: both variants adjust rSP around the 
vmload/vmrun/vmsave block - since these adjustments are already inverting
one another on 64-bits (and I'm making them so also on 32-bits), I would
think they could equally well both be left off - I think nothing inspects the
host VMCB while the guest is running, and hence nothing can get confused
by these pointing to a different stack slot.

Finally, is there a win of using an adjustment to rSP through add/sub
compared to using a push? I'd like to make the 64-bit save/restore
sequences symmetrical in either both skipping the RAX slot or both
pushing/popping a value (the pop would obviously go to a different
register, as the value must be discarded). I would even consider
replacing the whole push/pop sequences by using moves - this ought
to be faster, despite creating bigger code (assuming that the
throughput of moves is higher than that of back-to-back pushes/pops).

Jan

>>> "Petersson, Mats" <Mats.Petersson@xxxxxxx> 10.05.07 18:12 >>>


> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jan Beulich
> Sent: 10 May 2007 17:02
> To: xen-devel@xxxxxxxxxxxxxxxxxxx 
> Subject: [Xen-devel] svm vmexit action sequence
> 
> Is there any particular reason why on 32-bits the order is VMLOAD then
> HVM_SAVE_ALL_NOSEGREGS, while on 64-bits its is the other way around?
> Trying to put in the saving of EAX, I could save a 
> GET_CURRENT() on 32-bits
> if I could order things the same way as on 64-bits.

I don't see any reason why these shouldn't be the same (or at least as
similar as possible).
> 
> Also, both versions seem to have a redundant GET_CURRENT() right after
> the clgi/sti sequence - again, is there a particular reason for this?

No reason as far as I can tell. Assuming rbx (in 64-bit case) isn't
clobbered by called functions, that is. I can't remember for 64-bit if
rbx is "safe" or not. [It certainly is safe in 32-bit]. 

Thanks for spotting these things.

--
Mats
> 
> Thanks, Jan
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx 
> http://lists.xensource.com/xen-devel 
> 
> 
> 




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