Hi Srujan, this is the test application for xs_watch. It's written to use bogus path of /tool/test in xenstore to read the changes. It's creating a new thread and 1 minute countdown is running in the main thread to demonstrate the very same behaviour like it does in qemu-dm. Comments how to compile and use are written in the top of the C file. Hope this helps! Michal On 10/05/2010 04:21 PM, Srujan D. Kotikela wrote: > Hi Michal, > > Thanks for those suggestions. Will look into xs_watch() and get back > to you. Any pointers for the documentation would be appreciated. > thanks again. > > -- > Srujan D. Kotikela > > > On Tue, Oct 5, 2010 at 8:49 AM, Michal Novotny > wrote: > > Hi Srujan, > basically this would be the trigger-like mechanism using the > xenstore since it's using the xenstore watch facility itself if > you implement it as I recommend. I'm not suggesting using the > polling via xs_read() but you may study how to establish the > xs_watch. This is being done, for example, by qemu-dm for looking > for pci_ins/pci_del and USB hotplug stuff using the > xenstore_process_dm_command_event() function being called from the > xenstore_process_event for the XS_WATCH_TOKEN vector - see > tools/ioemu-dir/xenstore.c for reference. > > I think this method is OK since it's already used for watching the > hot-plug/hot-unplug stuff by the device model itself. Nevertheless > I don't know what exactly do you want to do and maybe it's better > to modify the hypervisor for your purpose but like I say, I don't > know the purpose why you need this. All I'm saying it that this > communication can be achieved using the xenstore watch > implementation of the user-space stack which is being used for > hot-plugging/hot-unplugging stuff already. > > Regards, > Michal > > > > On 10/05/2010 03:36 PM, Srujan D. Kotikela wrote: > > Hi Michal, > > I would prefer an trigger-like mechanism for communication > rather a a process where I have to constantly poll or look for > an event in DomU. How computing intensive would be xenstore > lookup compared to event-channels with 100s of DomUs? > > How about modifying hypervisor to do an upcall for the event > handler in Dom0 when a specific interrupt occurs in DomU? If > this can be done can you suggest any pointers for the same? > > Thanks for your help. > > -- > Srujan D. Kotikela > > > On Tue, Oct 5, 2010 at 8:22 AM, Michal Novotny > > >> wrote: > > Hi Srujan, > > I'm not that familiar with event channels themselves > however I was > thinking about using xenstore. You can modify the device model > (qemu-dm) to be watching some entry in the xenstore and the > communication could be both way since if you establish a > xenstore > watch in both Dom0 and DomU you could intercept the changes on > both sides. > > If you would like to use interrupts instead you may have to > modify > the HVMLoader source codes at tools/firmware/hvmloader of the > user-space stack but I think using the xenstore could do > the job > since this is how it's working with PV drivers AFAIK since PV > drivers themselves implement xenbus to connect to host's > xenstore > facility. > > Hope this helps! > > Cheers, > Michal > > > On 10/05/2010 03:14 PM, Srujan D. Kotikela wrote: > > Hi Michal, > > I have no special interest in SIGKILL. All I want to do is > notify Dom0 about an event in DomU (I don't need to > pass any > data). I am trying to indicate events by signals or > interrupts. It means, if a "particular" interrupt has > occurred > in DomU, the Dom0 should be notified. Is there any > other way > of doing the same other than using event channels? > > I am successful in establishing the event channel. But I am > not quite sure how to send a notification that an event > occurred in DomU to Dom0. Any pointers for the same > would be > appreciated. > > -- > Srujan D. Kotikela > > > On Tue, Oct 5, 2010 at 3:36 AM, Michal Novotny > > > > > >>> wrote: > > Hi Srujan, > what about adding a signal handler to qemu-dm in the > tools/ioemu-dir of the user-space tools? Using the > signal() > API? > Nevertheless why would you like to catch SIGKILL? > This one > (as can > be seen using included program source and killing it > using > kill -9 > pid or kill -SIGKILL pid) is not being caught at all > nevertheless > most of the other signals can be caught. > > This is the source of the example mentioned: > #include > #include > #include > > void sig_handler(int sig) { > fprintf(stderr, "Signal %d caught.\n", sig); > exit(sig); > } > > int main() > { > signal(SIGINT, sig_handler); > signal(SIGKILL, sig_handler); > > sleep(10000); > return 0; > } > > When I did try SIGINT (Ctrl + C or kill -2 pid) it > caught the > signal well but when I did try kill -9 pid (or kill > -SIGKILL pid > respectively) it was not working at all since it > killed the > process instead of going to the signal handler. When you > need to > catch signals like interruption signal (Ctrl + C > one) this will > work fine. > > Michal > > > On 10/04/2010 09:03 PM, Srujan D. Kotikela wrote: > > Hi, > > I am trying to capture SIGKILL through event > channel. > > On my Dom0, the following process is running > (remaining > code > in attachment). > > > int main(void){ > > int ret, dom, remote_dom; > > //initialize domains > dom=0; > remote_dom=2; > > //create the event channel > ret = create_channel(dom, remote_dom); > > > if (0 == ret) { > printf("\n Event Channel established > successfully \n"); > } else { > return -1; > //EVENT_CHANNEL_CREATION_FAILED > } > > //wait 20 seconds for an event to occur > in DomU > wait_for_event(20); > > //close the opened interfaces > close_channel(); > > return 0; > > } > > > While this process is running; I killed a > process in DomU > using `*kill SIGKILL pid*` > > How can I capture this event (occured in DomU) > at the > Dom0. I > watched /dev/xen/evtchn, but no notification. > > > -- > Srujan D. Kotikela > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > > > > > >> > > http://lists.xensource.com/xen-devel > > > > -- Michal Novotny > > > > > >>>, RHCE > > Virtualization Team (xen userspace), Red Hat > > > > > -- Michal Novotny >>, RHCE > Virtualization Team (xen userspace), Red Hat > > > > > -- > Michal Novotny>, RHCE > Virtualization Team (xen userspace), Red Hat > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat