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

One more question: both variants have HVM_SAVE_ALL_NOSEGREGS do a
forced reset of eflags/rflags - what is this needed for? #VMEXIT supposedly
restores them. 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