RE: [Xen-devel] evtchn_upcall_mask

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel