Andi Kleen wrote: >>Could you please elaborate on this one. I'd like to make sure I >>understand (since Xen uses some type of virtual interrupt mask to disable >>event channel). >> >> > >Yes, it needs some theory comment at least, otherwise the chance >of this not bit rotting extremly quickly is about zero. > > Since the paravirtualized guest can not change EFLAGS_IF via cli, sti, popf, or iret, these instructions need special support. In Xen, this is analogous to masking the event channel; in fact these diffs very nearly match up with the XenoLinux fault / trap handling code. Since there is no privileged processor state that can be safely used to indicate the interrupt mask by a kernel running above ring zero, this virtual interrupt mask must be stored in a memory word. Writing to that memory word requires a fixed base, writable data segment, so that a direct memory read/modify/write operation may be issued. In many places in this code, this is not true; sysenter is still running on user data segments, for example. This means in some places the exact encoding of the virtual "STI" instruction must change from: andl $~EFLAGS_IF, virtual_interrupt_mask to andl $~EFLAGS_IF, %ss:virtual_interrupt_mask Once registers have been saved, then the code is safe, but this avoids re-ordering the logic so that cli/sti are issued only when on kernel data segments. In general, we want to enable interrupts as soon as possible and avoid unnecessarily complicating this code with what would otherwise appear to be random motion of cli / sti. Note that IRET is never safe; it always runs on user data segments, and in some cases, the stack segment may even be 16-bit! Zach
