WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] capturing SIGKILL in DomU

To: "Srujan D. Kotikela" <ksrujandas@xxxxxxxxx>
Subject: Re: [Xen-devel] capturing SIGKILL in DomU
From: Michal Novotny <minovotn@xxxxxxxxxx>
Date: Tue, 05 Oct 2010 15:49:53 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Oct 2010 06:55:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimqkz-uzMqNayer_YUrrs+WZRky3wjoBaSBV267@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
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 <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 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
        <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 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 <stdio.h>
           #include <signal.h>
           #include <stdlib.h>

           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@xxxxxxxxxxxxxxxxxxx
        <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>
        <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx
        <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>>

        http://lists.xensource.com/xen-devel



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




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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>