On Tue, 2011-10-04 at 12:23 +0100, Daniel Castro wrote:
> On Tue, Oct 4, 2011 at 8:02 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Tue, 2011-10-04 at 11:57 +0100, Daniel Castro wrote:
> >> Hello List,
> >>
> >> I have been trying for several days to be able to wait for events and
> >> then continue execution based on the event received. My problem is in
> >> the wait_ring function of xenbus.c
> >> After debugging my test_and_clear_bit I corrected the error that
> >> allows me to receive ONE event, but after that the bit is never set
> >> again. My offset is always 2 (nr eq 2).
> >> Please, can someone explain me how struct shared_info and these two
> >> fields control the events that I can receive?
> >> unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> >> unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> >>
> >> I print the whole array Bit by Bit and I do not see a difference after
> >> the arrival of the event and before the arrival.
> >>
> >> I also checked struct vcpu_info fields: u8 evtchn_upcall_pending and
> >> u8 evtchn_upcall_mask to see if they are disabling the event delivery.
> >> No changes before or after.
> >
> > If git://github.com/evildani/seabios_patch.git master is up to date
> > then:
> > shared_info = malloc_high(sizeof(shared_info));
> > xatp.gpfn = ((unsigned long)shared_info << PAGE_SHIFT);
> > is wrong and you aren't registering the correct shared_info so you
> > aren't actually looking at the right bits, the change in behaviour is
> > just because you are now looking at different wrong bits.
> >
> > You need ">>" not "<<" (consider the relation between addresses and page
> > numbers...).
>
> Thanks, sorry for the typo, I just corrected it, the same behavior persists.
>
> The output for shinfo->evtchn_pending[2] is
> 11001100110011001100110011001100, which bit am I supposed to change?
evtchn2 is bit 2 in evtchn_pending[0] so it is none of the above. If
this were evtchn_pending[0] instead then it would be the third bit from
the right (the rightmost bit would be evtchn 0, the leftmost being
evtchn 31).
However this value for evtchn_pending[2] (which, in the 32 bit ABI,
contains the pending bits for evtchns 64-96) looks very dubious to me:
it's rather too regular and we can be pretty sure event channels up
there are not yet in use. I'm still not 100% convinced you are seeing
the actual shared info.
Does shinfo->wc_sec contains something approximating the number of
seconds since 00:00:00 UTC, Jan 1, 1970? (i.e. something close to "date
+%s")
> Here I am confused.
> Also I have: VCPU.0 evtchn_upcall_mask 11000010 AND evntchn_pending 11000010
(assuming you mean evtchn_upcall_pending not evtchn_pending)
Those values also seem a bit unlikely.
Although C only distinguishes zero and non-zero as truth values at least
on the Xen side evtchn_upcall_mask is generally set to exactly 1 or 0. A
guest may do otherwise, I think, but I don't think hvmloader or your
code are actually touching it.
> Sorry but I am somewhat confused by all this. Is this documented somewhere?
There are reasonably complete comments in xen/include/public/xen.h
associated with the fields in vcpu_info and shared_info which explain
what is going on. I think this is also one area where the existing
interface.pdf docs are actually ok, this ABI has been part of Xen since
3.0.0 (if not much earlier) so any book you have which covers it ought
to still be relevant.
Ian.
>
> Million Thanks again!
>
> >
> > Ian.
> >
> >
> >
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home