[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Xen/ia64 presentation
On 27 Apr 2005, at 21:08, Hollis Blanchard wrote: xen_regs/execution_context_t seems to mean "state which xen code could alter", so something to distinguish it from "all CPU state" would be nice. Maybe something like this:struct xen_state: (now xen_regs) state which xen C/asm code could alterstruct vcpu_state: (now exec_domain) all virtual CPU state struct arch_vcpu_state ("vcpu_regs" might not be good, since we could need to save other context like software-controlled TLBs, and so "xen_state" would match "vcpu_state".) x86 Xen makes the distinction between xen_regs and full_execution_context only because xen_regs is what gets saved on the stack on entry to / exit from Xen. More advanced state like TLB info could probably be saved directly into 'struct vcpu_state' where you detect that you have interrupted a guest activation. xen_regs/xen_state should probably be entirely arch-specific anyway. Even now it only pokes through into common code in interrupt-handler definitions (the final parameter is a xen_regs pointer). It'd be great to nuke those last few from common code. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |