From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Novotny Subject: Re: capturing SIGKILL in DomU Date: Tue, 05 Oct 2010 17:33:17 +0200 Message-ID: <4CAB453D.30008@redhat.com> References: <4CAAE39C.1020708@redhat.com> <4CAB26AA.6040300@redhat.com> <4CAB2D01.9010106@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080202060705060505090800" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Srujan D. Kotikela" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------080202060705060505090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------080202060705060505090800 Content-Type: text/x-csrc; name="xswatchtest.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xswatchtest.c" /* Simple demonstation of using xenstore watches by Michal Novotny Hard-coded to path of /tool/test in xenstore and token called "token". Please compile using: $ gcc -o xswatchtest xswatchtest.c -lxenstore -lpthread and run as root (otherwise it fails). It creates a new thread for watching, called "watcher" with xs_handle passed to it. Polling itself is done by select() on the xenstore file descriptor. This demo is running the countdown of 1 minute in the main thread and the secondary thread is polling on changes of /tool/test path in the xenstore. Please test by issuing: # xenstore-write /tool/test/some thing when running to see it's working fine. Hope this helps! Michal */ #include #include #include #include #define PATH "/tool/test" #define TOKEN "token" void *watcher(void *opaque); void *watcher(void *opaque) { int fd, num; fd_set fds; char **vec; struct xs_handle *xsh; xsh = opaque; fd = xs_fileno(xsh); FD_ZERO(&fds); FD_SET(fd, &fds); while (select(fd + 1, &fds, NULL, NULL, NULL) > 0) { vec = xs_read_watch(xsh, &num); if (vec != NULL) if (strcmp(vec[XS_WATCH_TOKEN], TOKEN) == 0) printf("Data on %s: %s\n", vec[XS_WATCH_PATH], xs_read(xsh, XBT_NULL, PATH, NULL)); } } int main() { pthread_t watch_thread; struct xs_handle *xsh; int i; xsh = xs_daemon_open(); if (xsh == NULL) { perror("Daemon open error"); return 1; } if (!xs_watch(xsh, PATH, TOKEN)) { fprintf(stderr, "Error when establishing a watch\n"); return 0; } pthread_create( &watch_thread, NULL, watcher, (void*) xsh); i = 0; while (i++ < 60) { printf("Sleeping. %d seconds remaining\n", 60 - i); sleep(1); } xs_unwatch(xsh, PATH, TOKEN); xs_daemon_close(xsh); return 0; } --------------080202060705060505090800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------080202060705060505090800--