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

[XenARM] [MINIOS] evtchn_pending_sel issue

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "xen-arm@xxxxxxxxxxxxxxxxxxx" <xen-arm@xxxxxxxxxxxxxxxxxxx>
Subject: [XenARM] [MINIOS] evtchn_pending_sel issue
From: ROSSIER Daniel <Daniel.Rossier@xxxxxxxxxx>
Date: Tue, 9 Jun 2009 17:43:29 +0200
Accept-language: fr-FR, en-US
Acceptlanguage: fr-FR, en-US
Cc:
Delivery-date: Tue, 09 Jun 2009 09:07:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-arm-request@lists.xensource.com?subject=help>
List-id: Xen ARM development <xen-arm.lists.xensource.com>
List-post: <mailto:xen-arm@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-arm>, <mailto:xen-arm-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-arm>, <mailto:xen-arm-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-arm-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnpGQkjpqUZTNe4REOqLxiWwEu5dg==
Thread-topic: [MINIOS] evtchn_pending_sel issue
Hi Folks,
 
Can anybody help us in the following problem:
(still working on embeddedXEN with ARM core)
 
we're trying to use miniOS (basically the same than x86 version) and we face a strange issue regarding
the hypervisor callback. Here is a portion of code:
 
#define active_evtchns(cpu,sh,idx)              \
    ((sh)->evtchn_pending[idx] &                \
     ~(sh)->evtchn_mask[idx])
 
l1 = xchg(&vcpu_info->evtchn_pending_sel, 0);
        while (l1 != 0) {
                l1i = __ffs(l1);
                l1 &= ~(1 << l1i);
                while ((l2 = active_evtchns(cpu, s, l1i)) != 0) {
                        l2i = __ffs(l2);
                        l2 &= ~(1 << l2i);
 
                        port = (l1i << 5) + l2i;
                        do_event(port, regs);
                }
        }
 
The timer init function bind the VIRQ_TIMER to a specific handler, ok. VIRQ_TIMER is equal to 0 and therefore, the bit 0 of
evtchn_pending and evtchn_mask are set correctly (checked). However, the code above tells us that l1i is set to 1 (and not 0).
Consequently, we never statisfy the second while() condition.
 
It seems that there is a shift of one bit in the computation of l1i, since _ffs return 1 for the least significant bit (and not 0).
What do you think?
 
What I'm wondering is how it could work .. (and probably it could ;-) just something that probably I missed….
 
Thanks for your help
 
Daniel
 
 
 
_______________________________________________
Xen-arm mailing list
Xen-arm@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-arm
<Prev in Thread] Current Thread [Next in Thread>