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 thePSR.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@lists.xensource.com http://lists.xensource.com/xen-devel
* Hollis Blanchard (hollisb@us.ibm.com) wrote:> 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.Is local_irq_disable() not enough abstraction in Linux? Oh, I see, you mean for both sides of the fence. From your description that makes perfect sense to me. thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Hollis Blanchard >Sent: 2006年6月10日 5:09 > >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.Same story for IA64, where PSR.i is always on when domain is running (ring 1 - 3).>>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.)Sorry that I''m not clear and maybe I shouldn''t use ''merge'' here. On IA64, xenlinux can''t modify PSR.i since it''s not running at ring level 0. So it''s always the same case to provide a virtual interrupt control bit which can be managed by domain directly. Before my change, that virtual bit was defined in some other places in shared page, when evtchn_upcall_pending already provides similar meaning which risks unnecessarily. Above so-called ''merge'' is actually to remove the former duplicated flag, and thus only keep evtchn_upcall_pending as the very bit. So for xen/ia64, that''s a real fix instead of a work around. :-)> >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?I understand your concern for correctness on PPC, and agree abstraction is required. Only note is to put IA64 into same category as x86 in this special case.> >(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.)Thanks for your info, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel