WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-devel] evtchn_upcall_mask

To: "Hollis Blanchard" <hollisb@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] evtchn_upcall_mask
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 12 Jun 2006 12:19:17 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, xen-ppc-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 11 Jun 2006 21:19:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaMCPRANOLXsmzKQWKMywp2fVRcawBzCcFQ
Thread-topic: [Xen-devel] evtchn_upcall_mask
>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

<Prev in Thread] Current Thread [Next in Thread>