>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
|
Home