This topic came up months ago (under the thread "make
hypercall_preempt_check() a little more sensitive"), but since then, due
to a misunderstanding, PPC has been running with a hack instead of a
solution. So anyways, I've been digging into this again.
PowerPC domains are allowed to write to the "interrupts enabled" bit
(called External Exceptions, or EE) in the hardware's Machine State
Register (MSR). Hardware allows domains to directly control this bit.
On x86, domains aren't allowed to cli/sti because they aren't running in
ring 0. So instead, they use a software flag (evtchn_upcall_mask) to
mean the same thing, and the domains can control that.
On 30 Mar 2006, Kevin Tian wrote:
> [...] we've merged our
> architecture specific interrupt enable flag with the evtchn_upcall_mask, to
> avoid any race conditions when operating two flags simultaneously. After
> this effort, now XEN/IA64 is completely same as x86 where
> evtchn_upcall_mask becomes the only flag for interrupts/events, to avoid
> any future similar misunderstandings."
>From what I can see, IA64 has a similar situation to PowerPC, where the
PSR.I bit controls interrupt delivery, and can be directly modified by
the domains.
(Note that when Kevin says "merged", I think what he really means is
that when entering Xen, IA64 code sets
current->vcpu_info->evtchn_upcall_mask according to PSR.I, and vice
versa when exiting. That seems to be working around the problem.)
Getting back to PPC, we have two flags that mean the same thing ("don't
deliver interrupts"): MSR:EE and v->vcpu_info->evtchn_upcall_mask. I
think it's far preferable to use the MSR as it's intended, for two
reasons:
1) Linux already does this.
2) A register write is much much faster than the several memory accesses
needed to read/write evtchn_upcall_mask, and disabling interrupts is a
hot path in Linux.
So I'd like to abstract users of evtchn_upcall_mask in Xen (and Linux,
mini-os, etc) into set/get accessors. On PPC and IA64, the accessors
would deal directly with the register state, and the field itself
wouldn't even exist.
Thoughts?
(There's a particular bug that I'm trying to solve which I can describe
if needed, but I think the general design question is valid.)
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home