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. Also, both versions seem to have a redundant GET_CURRENT() right after the clgi/sti sequence - again, is there a particular reason for this? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jan Beulich > Sent: 10 May 2007 17:02 > To: xen-devel@lists.xensource.com > 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@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@amd.com> 10.05.07 18:12 >>>> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jan Beulich > Sent: 10 May 2007 17:02 > To: xen-devel@lists.xensource.com > 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@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
See the unstable staging tree for some changes already in this area. As you can see there is still quite some scope for improvement - I bet we can just get rid of this push/popf pair for example. And the horrendous VMLOAD/VMSAVE/VMLOAD/VMSAVE sequence can probably be shoved off at least to only context switches. -- Keir On 11/5/07 08:28, "Jan Beulich" <jbeulich@novell.com> wrote:> 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@amd.com> 10.05.07 18:12 >>> > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >> Jan Beulich >> Sent: 10 May 2007 17:02 >> To: xen-devel@lists.xensource.com >> 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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> >> > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@amd.com> 10.05.07 18:12 >>>> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jan Beulich > Sent: 10 May 2007 17:02 > To: xen-devel@lists.xensource.com > 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@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/5/07 08:42, "Jan Beulich" <jbeulich@novell.com> wrote:> 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).If moves can be measured as faster than pushes/pops on a reasonable range of processors, it would make sense to change all our entry/exit sequences rather than just this one and stick to one idiom (push/pop) or the other (mov). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Reasonably Related Threads
- [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler
- [PATCH 0/3] x86: adjust entry frame generation
- Communication between guest OS and VMM
- [PATCH] x86-64: drop updating of UREGS_rip when converting sysenter to #GP
- A different probklem with save/restore on C/S 14823.