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. Thank you very much for everyones time, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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...). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Castro
2011-Oct-04 11:23 UTC
Re: [Xen-devel] Help with test_and_clear_bit on events
On Tue, Oct 4, 2011 at 8:02 PM, Ian Campbell <Ian.Campbell@citrix.com> 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? Here I am confused. Also I have: VCPU.0 evtchn_upcall_mask 11000010 AND evntchn_pending 11000010 Sorry but I am somewhat confused by all this. Is this documented somewhere? Million Thanks again!> > Ian. > > >-- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@citrix.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2011-10-04 at 12:02 +0100, Ian Campbell 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));Another bug here. sizeof(shared_info) is sizeof the pointer (i.e. 4), not the data structure which it points to. You could use sizeof(*shared_info) but actually you require a page size and page aligned allocation so you should just use PAGE_SIZE. If your allocation is not page aligned the shift to calculate gpfn will effectively round down the address you wanted...> 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...). > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 14:15 +0100 on 04 Oct (1317737710), Ian Campbell wrote:> On Tue, 2011-10-04 at 12:23 +0100, Daniel Castro wrote: > > The output for shinfo->evtchn_pending[2] is > > 11001100110011001100110011001100, which bit am I supposed to change? > > 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.In particular this is 0xcccccccc , which is a string of x86 NOPs - are you sure this isn''t the hypercall page by mistake? Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2011-10-04 at 14:19 +0100, Ian Campbell wrote:
Two more bugs:
A domid is 16 bits not 64, see struct xen_add_to_physmap. So the
structure passed to the hypercall doesn''t line up and you
don''t really
end up with the shared info in the right place.
Secondly in:
int wait = test_and_clear_bit(event, shinfo->evtchn_pending);
int ret = 1;
while (!wait || ret){
ret = hypercall_sched_op(SCHEDOP_poll, &poll);
wait = test_and_clear_bit(event, shinfo->evtchn_pending);
}
This will always go through the loop at least once, even if wait is
already true because ret == 1. But if wait was already one then you have
cleared the bit so wait will then become 0 on the first time through the
loop and since you won''t get any more events you get stuck in the loop.
I think you meant && !ret or something, but really you should be doing
BUG on !ret.
With all those fixed things seem to work for me. I do
xenstore-write /local/domain/$(xl domid dHVM-1)/device/vbd/768/test foo
twice to get through the test code and it continues on to boot the
guest.
My patch (with debug and hacks included) is below.
Ian.
diff --git a/src/xen-xs.c b/src/xen-xs.c
index 9f583f9..4c208d4 100644
--- a/src/xen-xs.c
+++ b/src/xen-xs.c
@@ -126,14 +126,21 @@ static void ring_wait(void)
memset(&poll, 0, sizeof(poll));
set_xen_guest_handle(poll.ports, &event);
poll.nr_ports = 1;
- dprintf(1,"evtchn_pending 0x%p , 0x%lx at event %d
\n",shinfo->evtchn_pending,shinfo->evtchn_pending[event],event);
+ dprintf(1, "shared info %p\n", shinfo);
+ dprintf(1,"evtchn_pending %p , 0x%lx at event %d
\n",shinfo->evtchn_pending,shinfo->evtchn_pending[0],event);
+ while ( !test_and_clear_bit(event, shinfo->evtchn_pending) )
+ hypercall_sched_op(SCHEDOP_poll, &poll);
+
+#if 0
int wait = test_and_clear_bit(event, shinfo->evtchn_pending);
- int ret = 1;
+ int ret = 0;
+ dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret);
while (!wait || ret){
ret = hypercall_sched_op(SCHEDOP_poll, &poll);
wait = test_and_clear_bit(event, shinfo->evtchn_pending);
dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret);
}
+#endif
}
static void ring_wait2(void)
diff --git a/src/xen.c b/src/xen.c
index e8469b0..312c206 100644
--- a/src/xen.c
+++ b/src/xen.c
@@ -154,11 +154,20 @@ struct shared_info *get_shared_info(void)
xatp.domid = DOMID_SELF;
xatp.space = XENMAPSPACE_shared_info;
xatp.idx = 0;
- shared_info = malloc_high(sizeof(shared_info));
- xatp.gpfn = ((unsigned long)shared_info << PAGE_SHIFT);
+ shared_info = memalign_high(PAGE_SIZE, PAGE_SIZE);
+ memset(shared_info, 0, PAGE_SIZE);
+ xatp.gpfn = ((unsigned long)shared_info >> PAGE_SHIFT);
+ dprintf(1, "allocated shared info %d bytes at %p, gpfn 0x%lx\n",
+ sizeof(*shared_info), shared_info, xatp.gpfn);
//xatp.gpfn = malloc_high(sizeof(shared_info));
//shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT);
if (hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0)
panic("MAP info page fail");
+ dprintf(1, "time is %d\n", shared_info->wc_sec);
+ dprintf(1, "evtchn_pending[0] 0x%08lx\n",
shared_info->evtchn_pending[0]);
+ dprintf(1, "evtchn_mask[0] 0x%08lx\n",
shared_info->evtchn_mask[0]);
+ dprintf(1, "VCPU0 evtchn_upcall_pending 0x%x\n",
shared_info->vcpu_info[0].evtchn_upcall_pending);
+ dprintf(1, "VCPU0 evtchn_upcall_mask 0x%x\n",
shared_info->vcpu_info[0].evtchn_upcall_mask);
+ dprintf(1, "VCPU0 evtchn_pending_sel 0x%08lx\n",
shared_info->vcpu_info[0].evtchn_pending_sel);
return shared_info;
}
diff --git a/src/xen.h b/src/xen.h
index 1317af9..d838a7c 100644
--- a/src/xen.h
+++ b/src/xen.h
@@ -480,7 +480,7 @@ static struct xsd_errors __attribute__ ((unused))
xsd_errors[]
#define XENMEM_add_to_physmap 7
struct xen_add_to_physmap {
/* Which domain to change the mapping for. */
- u64 domid;
+ u16 domid;
/* Source mapping space. */
#define XENMAPSPACE_shared_info 0 /* shared info page */
@@ -503,7 +503,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
/*
* Wrappers for hypercalls
*/
-static int hypercall_xen_version( int cmd, void *arg)
+static inline int hypercall_xen_version( int cmd, void *arg)
{
return _hypercall2(int, xen_version, cmd, arg);
}
@@ -520,7 +520,7 @@ static inline int hypercall_event_channel_op(int cmd, void
*arg)
static inline int hypercall_memory_op(int cmd ,void *arg)
{
- return _hypercall2(int, memory_op, cmd ,arg);
+ return _hypercall2(int, memory_op, cmd, arg);
}
static inline int hypercall_sched_op(int cmd, void *arg)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Daniel Castro
2011-Oct-05 09:27 UTC
Re: [Xen-devel] Help with test_and_clear_bit on events
On Tue, Oct 4, 2011 at 11:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Tue, 2011-10-04 at 14:19 +0100, Ian Campbell wrote: > > Two more bugs: > > A domid is 16 bits not 64, see struct xen_add_to_physmap. So the > structure passed to the hypercall doesn''t line up and you don''t really > end up with the shared info in the right place. > > Secondly in: > > int wait = test_and_clear_bit(event, shinfo->evtchn_pending); > int ret = 1; > while (!wait || ret){ > ret = hypercall_sched_op(SCHEDOP_poll, &poll); > wait = test_and_clear_bit(event, shinfo->evtchn_pending); > } > > This will always go through the loop at least once, even if wait is > already true because ret == 1. But if wait was already one then you have > cleared the bit so wait will then become 0 on the first time through the > loop and since you won''t get any more events you get stuck in the loop. > I think you meant && !ret or something, but really you should be doing > BUG on !ret. > > With all those fixed things seem to work for me. I do > xenstore-write /local/domain/$(xl domid dHVM-1)/device/vbd/768/test foo > twice to get through the test code and it continues on to boot the > guest.Thank you Ian, it works flawlessly... Sorry about the bug. Github repo is up to date. With this, do you consider that any other xenbus functionality should be added? It can read, write, directory and watch. Maybe, unwatch? Shall I continue with the blk rings?> > My patch (with debug and hacks included) is below. > > Ian. > > diff --git a/src/xen-xs.c b/src/xen-xs.c > index 9f583f9..4c208d4 100644 > --- a/src/xen-xs.c > +++ b/src/xen-xs.c > @@ -126,14 +126,21 @@ static void ring_wait(void) > memset(&poll, 0, sizeof(poll)); > set_xen_guest_handle(poll.ports, &event); > poll.nr_ports = 1; > - dprintf(1,"evtchn_pending 0x%p , 0x%lx at event %d \n",shinfo->evtchn_pending,shinfo->evtchn_pending[event],event); > + dprintf(1, "shared info %p\n", shinfo); > + dprintf(1,"evtchn_pending %p , 0x%lx at event %d \n",shinfo->evtchn_pending,shinfo->evtchn_pending[0],event); > + while ( !test_and_clear_bit(event, shinfo->evtchn_pending) ) > + hypercall_sched_op(SCHEDOP_poll, &poll); > + > +#if 0 > int wait = test_and_clear_bit(event, shinfo->evtchn_pending); > - int ret = 1; > + int ret = 0; > + dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret); > while (!wait || ret){ > ret = hypercall_sched_op(SCHEDOP_poll, &poll); > wait = test_and_clear_bit(event, shinfo->evtchn_pending); > dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret); > } > +#endif > } > > static void ring_wait2(void) > diff --git a/src/xen.c b/src/xen.c > index e8469b0..312c206 100644 > --- a/src/xen.c > +++ b/src/xen.c > @@ -154,11 +154,20 @@ struct shared_info *get_shared_info(void) > xatp.domid = DOMID_SELF; > xatp.space = XENMAPSPACE_shared_info; > xatp.idx = 0; > - shared_info = malloc_high(sizeof(shared_info)); > - xatp.gpfn = ((unsigned long)shared_info << PAGE_SHIFT); > + shared_info = memalign_high(PAGE_SIZE, PAGE_SIZE);Here was my big mistake...> + memset(shared_info, 0, PAGE_SIZE); > + xatp.gpfn = ((unsigned long)shared_info >> PAGE_SHIFT); > + dprintf(1, "allocated shared info %d bytes at %p, gpfn 0x%lx\n", > + sizeof(*shared_info), shared_info, xatp.gpfn); > //xatp.gpfn = malloc_high(sizeof(shared_info)); > //shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT); > if (hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0) > panic("MAP info page fail"); > + dprintf(1, "time is %d\n", shared_info->wc_sec); > + dprintf(1, "evtchn_pending[0] 0x%08lx\n", shared_info->evtchn_pending[0]); > + dprintf(1, "evtchn_mask[0] 0x%08lx\n", shared_info->evtchn_mask[0]); > + dprintf(1, "VCPU0 evtchn_upcall_pending 0x%x\n", shared_info->vcpu_info[0].evtchn_upcall_pending); > + dprintf(1, "VCPU0 evtchn_upcall_mask 0x%x\n", shared_info->vcpu_info[0].evtchn_upcall_mask); > + dprintf(1, "VCPU0 evtchn_pending_sel 0x%08lx\n", shared_info->vcpu_info[0].evtchn_pending_sel); > return shared_info; > } > diff --git a/src/xen.h b/src/xen.h > index 1317af9..d838a7c 100644 > --- a/src/xen.h > +++ b/src/xen.h > @@ -480,7 +480,7 @@ static struct xsd_errors __attribute__ ((unused)) xsd_errors[] > #define XENMEM_add_to_physmap 7 > struct xen_add_to_physmap { > /* Which domain to change the mapping for. */ > - u64 domid; > + u16 domid; > > /* Source mapping space. */ > #define XENMAPSPACE_shared_info 0 /* shared info page */ > @@ -503,7 +503,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); > /* > * Wrappers for hypercalls > */ > -static int hypercall_xen_version( int cmd, void *arg) > +static inline int hypercall_xen_version( int cmd, void *arg) > { > return _hypercall2(int, xen_version, cmd, arg); > } > @@ -520,7 +520,7 @@ static inline int hypercall_event_channel_op(int cmd, void *arg) > > static inline int hypercall_memory_op(int cmd ,void *arg) > { > - return _hypercall2(int, memory_op, cmd ,arg); > + return _hypercall2(int, memory_op, cmd, arg); > } > > static inline int hypercall_sched_op(int cmd, void *arg) > > >-- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2011-10-05 at 10:27 +0100, Daniel Castro wrote:> On Tue, Oct 4, 2011 at 11:11 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Tue, 2011-10-04 at 14:19 +0100, Ian Campbell wrote: > > > > Two more bugs: > > > > A domid is 16 bits not 64, see struct xen_add_to_physmap. So the > > structure passed to the hypercall doesn''t line up and you don''t really > > end up with the shared info in the right place. > > > > Secondly in: > > > > int wait = test_and_clear_bit(event, shinfo->evtchn_pending); > > int ret = 1; > > while (!wait || ret){ > > ret = hypercall_sched_op(SCHEDOP_poll, &poll); > > wait = test_and_clear_bit(event, shinfo->evtchn_pending); > > } > > > > This will always go through the loop at least once, even if wait is > > already true because ret == 1. But if wait was already one then you have > > cleared the bit so wait will then become 0 on the first time through the > > loop and since you won''t get any more events you get stuck in the loop. > > I think you meant && !ret or something, but really you should be doing > > BUG on !ret. > > > > With all those fixed things seem to work for me. I do > > xenstore-write /local/domain/$(xl domid dHVM-1)/device/vbd/768/test foo > > twice to get through the test code and it continues on to boot the > > guest. > > Thank you Ian, it works flawlessly... Sorry about the bug. Github repo > is up to date. > With this, do you consider that any other xenbus functionality should > be added? It can read, write, directory and watch. Maybe, unwatch?Now that you have the basic infrastructure working I think you can just add what you need as you need it. I suspect you won''t actually need watch/unwatch since you can just poll the node.> Shall I continue with the blk rings?Yeah!> > > > > My patch (with debug and hacks included) is below. > > > > Ian. > > > > diff --git a/src/xen-xs.c b/src/xen-xs.c > > index 9f583f9..4c208d4 100644 > > --- a/src/xen-xs.c > > +++ b/src/xen-xs.c > > @@ -126,14 +126,21 @@ static void ring_wait(void) > > memset(&poll, 0, sizeof(poll)); > > set_xen_guest_handle(poll.ports, &event); > > poll.nr_ports = 1; > > - dprintf(1,"evtchn_pending 0x%p , 0x%lx at event %d \n",shinfo->evtchn_pending,shinfo->evtchn_pending[event],event); > > + dprintf(1, "shared info %p\n", shinfo); > > + dprintf(1,"evtchn_pending %p , 0x%lx at event %d \n",shinfo->evtchn_pending,shinfo->evtchn_pending[0],event); > > + while ( !test_and_clear_bit(event, shinfo->evtchn_pending) ) > > + hypercall_sched_op(SCHEDOP_poll, &poll); > > + > > +#if 0 > > int wait = test_and_clear_bit(event, shinfo->evtchn_pending); > > - int ret = 1; > > + int ret = 0; > > + dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret); > > while (!wait || ret){ > > ret = hypercall_sched_op(SCHEDOP_poll, &poll); > > wait = test_and_clear_bit(event, shinfo->evtchn_pending); > > dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret); > > } > > +#endif > > } > > > > static void ring_wait2(void) > > diff --git a/src/xen.c b/src/xen.c > > index e8469b0..312c206 100644 > > --- a/src/xen.c > > +++ b/src/xen.c > > @@ -154,11 +154,20 @@ struct shared_info *get_shared_info(void) > > xatp.domid = DOMID_SELF; > > xatp.space = XENMAPSPACE_shared_info; > > xatp.idx = 0; > > - shared_info = malloc_high(sizeof(shared_info)); > > - xatp.gpfn = ((unsigned long)shared_info << PAGE_SHIFT); > > + shared_info = memalign_high(PAGE_SIZE, PAGE_SIZE); > > Here was my big mistake... > > > + memset(shared_info, 0, PAGE_SIZE); > > + xatp.gpfn = ((unsigned long)shared_info >> PAGE_SHIFT); > > + dprintf(1, "allocated shared info %d bytes at %p, gpfn 0x%lx\n", > > + sizeof(*shared_info), shared_info, xatp.gpfn); > > //xatp.gpfn = malloc_high(sizeof(shared_info)); > > //shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT); > > if (hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0) > > panic("MAP info page fail"); > > + dprintf(1, "time is %d\n", shared_info->wc_sec); > > + dprintf(1, "evtchn_pending[0] 0x%08lx\n", shared_info->evtchn_pending[0]); > > + dprintf(1, "evtchn_mask[0] 0x%08lx\n", shared_info->evtchn_mask[0]); > > + dprintf(1, "VCPU0 evtchn_upcall_pending 0x%x\n", shared_info->vcpu_info[0].evtchn_upcall_pending); > > + dprintf(1, "VCPU0 evtchn_upcall_mask 0x%x\n", shared_info->vcpu_info[0].evtchn_upcall_mask); > > + dprintf(1, "VCPU0 evtchn_pending_sel 0x%08lx\n", shared_info->vcpu_info[0].evtchn_pending_sel); > > return shared_info; > > } > > diff --git a/src/xen.h b/src/xen.h > > index 1317af9..d838a7c 100644 > > --- a/src/xen.h > > +++ b/src/xen.h > > @@ -480,7 +480,7 @@ static struct xsd_errors __attribute__ ((unused)) xsd_errors[] > > #define XENMEM_add_to_physmap 7 > > struct xen_add_to_physmap { > > /* Which domain to change the mapping for. */ > > - u64 domid; > > + u16 domid; > > > > /* Source mapping space. */ > > #define XENMAPSPACE_shared_info 0 /* shared info page */ > > @@ -503,7 +503,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); > > /* > > * Wrappers for hypercalls > > */ > > -static int hypercall_xen_version( int cmd, void *arg) > > +static inline int hypercall_xen_version( int cmd, void *arg) > > { > > return _hypercall2(int, xen_version, cmd, arg); > > } > > @@ -520,7 +520,7 @@ static inline int hypercall_event_channel_op(int cmd, void *arg) > > > > static inline int hypercall_memory_op(int cmd ,void *arg) > > { > > - return _hypercall2(int, memory_op, cmd ,arg); > > + return _hypercall2(int, memory_op, cmd, arg); > > } > > > > static inline int hypercall_sched_op(int cmd, void *arg) > > > > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel