From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Paravirtualization of the "HLT" instruction (for example) on x386 Date: Sat, 28 Jan 2006 16:06:50 -0600 Message-ID: <43DBEAFA.3010704@us.ibm.com> References: <60c562438f7299b8b178aa9b70cd6997@cl.cam.ac.uk> <9aeefb8a24491cfdcda09e814f95fe81@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Ryden Cc: Ian Brown , Xen Mailing List List-Id: xen-devel@lists.xenproject.org Mark Ryden wrote: >>Furthermore, some instructions *have* to be paravirtualised because >>they do not trap >> >> > >So all the instances of such instructions which don't trap and are >problemtaic in some sense , under the linux-xen0 and linux-xenU, are >replaced ? Did I get it right ? > > Yes, a very thorough explaination of this all is available here: http://www.cs.nps.navy.mil/people/faculty/irvine/publications/2000/VMM-usenix00-0611.pdf Regards, Anthony Liguori >Mark > > > >On 1/24/06, Keir Fraser wrote: > > >>On 24 Jan 2006, at 11:27, Ian Brown wrote: >> >> >> >>>I know that CLTS and WBINVD instructions, for example , should cause >>>#GP(0) if run from CPL which is not 0; but grepping for an asm >>>instruction >>>which calls CLTS or WBINVD under the sparse tree gives no results. >>> >>>Can you give one example for such an instruction which cause a trap >>>to the hypervisor when run in a guest OS and where in the code it >>>causes >>>such a trap ? >>> >>>(As far as I understand,if we try to issue a privilege instruction from >>>CPL1 we should get a #GP(0) and reach the general protection >>>handler in sparse/arch/xen/i386/kernel/traps.c , >>>do_general_protection(). >>> >>>But I had looked at do_general_protection() in >>>sparse/arch/xen/i386/kernel/traps.c >>>and could not find there a mechanism which will trap to the >>>hypervisor;maybe >>>I had totally missed the point?) >>> >>> >>The main entry point for GPFs is in the hypervisor at >>do_general_protection() in xen/arch/x86/traps.c. For certain privileged >>instructions we perform emulation (see emulate_privileged_op() in the >>same Xen source file). We emulate both CLTS and WBINVD for example. >>GPFs that are not handled by Xen are indeed then passed to the guest >>and will end up in the function you mentioned in your email. >> >>However, we also have paravirtualised versions of both those >>instructions (for example, CLTS is equivalent to the hypercall >>fpu_taskswitch(0)). >> >>Furthermore, some instructions *have* to be paravirtualised because >>they do not trap (for example, POPF where the restored EFLAGS has a >>different Interrupt-Enable flag value from current EFLAGS). >> >> -- Keir >> >> >>_______________________________________________ >>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 > > >