This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] capturing SIGKILL in DomU

To: Michal Novotny <minovotn@xxxxxxxxxx>
Subject: Re: [Xen-devel] capturing SIGKILL in DomU
From: "Srujan D. Kotikela" <ksrujandas@xxxxxxxxx>
Date: Tue, 5 Oct 2010 18:09:52 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Oct 2010 16:10:49 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qSXKUpDgPXfk+g9LZLTALPeDMrXlOh2GTWPGgcsqwUU=; b=KOgAL4EeBu/YXTNS0y6AvzpJvL+6gX90iOZUwqKhIhi11QXpEbyD7LIsBo8URSsTjm 4JIyHo9aSQRlNHAjlOiKxod+DSb1yRuLAv6fnux/7986iax6aQrIxy9+OMTANnA+GZeb OgqbhMGMtPa6Pb1yz0Oj4HUIThkvK/MATp0iE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HOJfeWMYypfKOwqthTKt776JiyzprMw6/R76kEKzhHUP4GV5z6C6J95gU9Xk/Ty/Wt anjgObe90k7iEsFsSYXuoPtCXU6lZmkNxmwjmptmrd808XLWfQMVgm71hV7mYA8fCgd+ T3JxWDwDMFOr75AEDKyiLa07LQPnKii6u2iMw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CAB453D.30008@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTi=0bFWS0zOrD49b5iDaG3y7K_90UBCOJ+RieUvj@xxxxxxxxxxxxxx> <4CAAE39C.1020708@xxxxxxxxxx> <AANLkTin7wzK4qnUageGQFw5P3jwd6YRjok1Pgm-rjZz-@xxxxxxxxxxxxxx> <4CAB26AA.6040300@xxxxxxxxxx> <AANLkTimqkz-uzMqNayer_YUrrs+WZRky3wjoBaSBV267@xxxxxxxxxxxxxx> <4CAB2D01.9010106@xxxxxxxxxx> <AANLkTik7eMGOY0z0=V70OVjyrDSOgDUMgKAQgO2VnWu_@xxxxxxxxxxxxxx> <4CAB453D.30008@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Michal,

Thanks a lot for that example. Will check it and get back to you.

Srujan D. Kotikela

On Tue, Oct 5, 2010 at 10:33 AM, Michal Novotny <minovotn@xxxxxxxxxx> wrote:
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!

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 <minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>> 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.


   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
       <minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>
       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>>> 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
          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
          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

          Hope this helps!


          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
              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

              Srujan D. Kotikela

              On Tue, Oct 5, 2010 at 3:36 AM, Michal Novotny
       <minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>
       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>>
       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>
       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>>>> wrote:

                 Hi Srujan,
                 what about adding a signal handler to qemu-dm in the
                 tools/ioemu-dir of the user-space tools? Using the
                 Nevertheless why would you like to catch SIGKILL?
       This one
              (as can
                 be seen using included program source and killing it
              kill -9
                 pid or kill -SIGKILL pid) is not being caught at all
                 most of the other signals can be caught.

                 This is the source of the example mentioned:
                 #include <stdio.h>
                 #include <signal.h>
                 #include <stdlib.h>

                 void sig_handler(int sig) {
                    fprintf(stderr, "Signal %d caught.\n", sig);

                 int main()
                    signal(SIGINT, sig_handler);
                    signal(SIGKILL, sig_handler);

                    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.


                 On 10/04/2010 09:03 PM, Srujan D. Kotikela wrote:


                     I am trying to capture SIGKILL through event

                     On my Dom0, the following process is running
                     in attachment).

                        int main(void){

                            int ret, dom, remote_dom;

                            //initialize domains

                            //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

                            //close the opened interfaces

                            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


                 --     Michal Novotny<minovotn@xxxxxxxxxx
       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>>
       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>

       <mailto:minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>>>>, RHCE

                 Virtualization Team (xen userspace), Red Hat

          --     Michal Novotny<minovotn@xxxxxxxxxx
       <mailto:minovotn@xxxxxxxxxx> <mailto:minovotn@xxxxxxxxxx
       <mailto:minovotn@xxxxxxxxxx>>>, RHCE
          Virtualization Team (xen userspace), Red Hat

   --     Michal Novotny<minovotn@xxxxxxxxxx <mailto:minovotn@xxxxxxxxxx>>, RHCE
   Virtualization Team (xen userspace), Red Hat

Xen-devel mailing list

Michal Novotny<minovotn@xxxxxxxxxx>, RHCE

Virtualization Team (xen userspace), Red Hat

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>