Re: capturing SIGKILL in DomU

[Michal Novotny <minovotn@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 10107 bytes --]

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 <minovotn@redhat.com 
> <mailto:minovotn@redhat.com>> 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
>         <minovotn@redhat.com <mailto:minovotn@redhat.com>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>>> 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@redhat.com <mailto:minovotn@redhat.com>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>>>> 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@lists.xensource.com
>         <mailto:Xen-devel@lists.xensource.com>
>         <mailto:Xen-devel@lists.xensource.com
>         <mailto:Xen-devel@lists.xensource.com>>
>         <mailto:Xen-devel@lists.xensource.com
>         <mailto:Xen-devel@lists.xensource.com>
>         <mailto:Xen-devel@lists.xensource.com
>         <mailto:Xen-devel@lists.xensource.com>>>
>
>         http://lists.xensource.com/xen-devel
>
>
>
>                   --     Michal Novotny<minovotn@redhat.com
>         <mailto:minovotn@redhat.com>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>
>
>         <mailto:minovotn@redhat.com <mailto:minovotn@redhat.com>>>>, RHCE
>
>                   Virtualization Team (xen userspace), Red Hat
>
>
>
>
>            --     Michal Novotny<minovotn@redhat.com
>         <mailto:minovotn@redhat.com> <mailto:minovotn@redhat.com
>         <mailto:minovotn@redhat.com>>>, RHCE
>            Virtualization Team (xen userspace), Red Hat
>
>
>
>
>     -- 
>     Michal Novotny<minovotn@redhat.com <mailto:minovotn@redhat.com>>, RHCE
>     Virtualization Team (xen userspace), Red Hat
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    


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


[-- Attachment #2: xswatchtest.c --]
[-- Type: text/x-csrc, Size: 1941 bytes --]

/*
  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 <stdio.h>
#include <xs.h>
#include <sys/select.h>
#include <pthread.h>

#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;
}


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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