[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Clock Interrupt not occurring. hypervisor_callback not being called. (more info)


  • To: "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>
  • From: "Ivan Kelly" <ivanbkelly@xxxxxxxxx>
  • Date: Wed, 1 Mar 2006 22:29:57 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 01 Mar 2006 22:30:26 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KmCfZJ4QjCXEYZh8bX8YhnUuNnsmuDXD9vojcywC4sUUU/4XeFk42r7/dTHV//4pACe2rfqvnPQkQpCo6892m/xOWm/2wmPe12pIkNfY9OcV2doqxuWxDe7a86NWu/Mdup6XXMBikqT2kecVKIjgUNjFj/YcOIQDIyZeVjzAgvM=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

how would one create a memory barrier? I think the xchg asm
instruction should be a natural barrier in any case.
-Ivan

On 3/1/06, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx> wrote:
> Ivan,
>
> How about a memory barrier right before the call to evtchn_notify
> in evtchn_set_pending and one before l1 =
> x86_atomic_xchg(&s->evtchn_pending_sel, 0)
> in do_hypervisor_callback?
>
> Regards,
> Dave
>
>
> Ivan Kelly wrote:
>
> >Some more info on this problem.
> >The problem seems to be that evtchn_pending[0] is not being updated
> >fast enough after the callback is made. Therefore the callback is
> >running and seeing nothing as pending and discarding anything that
> >happens.
> >If i put in something that delays before the start of the inner loop
> >somewhere, it will work fine. It doesn't have to be a printf, can be a
> >for(i=0;i<100000;i++) or something similar.
> >evtchn_pending is set as volatile. Im not sure if this is actually
> >helping at all though, since I have to use the ACK compiler which is
> >the only thing that minix will compile with.
> >
> >Does anyone have any idea on how i can get evtchn_pending to update on time?
> >Regards
> >Ivan
> >
> >
> >
> >><SNIP>
> >>PUBLIC void
> >>do_hypervisor_callback(struct stackframe_s *regs)
> >>{
> >>        unsigned long  l1, l2;
> >>        unsigned int   l1i, l2i, port;
> >>        int            irq;
> >>        shared_info_t *s = hypervisor_shared_info;
> >>
> >>        s->vcpu_data[0].evtchn_upcall_pending = 0;
> >>
> >>        l1 = x86_atomic_xchg(&s->evtchn_pending_sel, 0);
> >>
> >>        while ( l1 != 0 )
> >>        {
> >>/*              kprintf("l1: %x\n");*/
> >>                l1i = x86_scan_forward(l1);
> >>                l1 &= ~(1 << l1i);
> >>
> >>                l2 = s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i];
> >>                while ( l2 != 0 )
> >>                {
> >>                        kprintf("l2: %x\n", l2);
> >>                        l2i = x86_scan_forward(l2);
> >>                        l2 &= ~(1 << l2i);
> >>
> >>                        port = (l1i << 5) + l2i;
> >>
> >>                        if ( (irq = event_to_action[port]) != -1 ) {
> >>                                do_event(irq, regs);
> >>                        }
> >>                }
> >>        }
> >>}
> >><ENDSNIP>
> >>
> >>
> >>
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel
> >
> >
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.