[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Paravirtualization of the "HLT" instruction (for example) on x386
>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 ? Mark On 1/24/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |