* capturing SIGKILL in DomU
@ 2010-10-04 19:03 Srujan D. Kotikela
2010-10-05 8:36 ` Michal Novotny
0 siblings, 1 reply; 9+ messages in thread
From: Srujan D. Kotikela @ 2010-10-04 19:03 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 890 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 1191 bytes --]
[-- Attachment #2: EcTest.c --]
[-- Type: text/x-csrc, Size: 1999 bytes --]
#include <stdint.h>
#include <stdio.h>
#include <xenctrl.h>
#include <xen/xen.h>
#include <xen/event_channel.h>
static int xce_handle = -1;
static int src_port = -1;
static int dst_port = -1;
static int xc_handle = -1;
int create_channel(int dom, int remote_dom) {
//open the hypervisor interface
if (-1 != (xc_handle=xc_interface_open())) {
// printf("\n Accquired HYPERVISOR INTERFACE HANDLE: %d \n", xc_handle);
} else {
return -1; //HYPERVISOR_INTERFACE_OPEN_FAIL
}
//allocate a port on the remote domain
if (-1 != (dst_port = xc_evtchn_alloc_unbound(xc_handle, remote_dom, dom))) {
// printf("\n Allocated the DEST port %d \n", dst_port);
} else {
return -2; //UNBOUND_PORT_ALLOCATION_FAIL
}
//create a handle for event channel
if (-1 != (xce_handle = xc_evtchn_open())) {
// printf("\n Accquired HYPERVISOR INTERFACE EVTCHN HANDLE: %d\n", xce_handle);
} else {
return -3; //EVENT_CHANN //create the event channelEL_OPEN_FAIL
}
//bind src and dst ports
if(-1 != (src_port = xc_evtchn_bind_interdomain(xce_handle, remote_dom, dst_port))) {
// printf("\n Allocated the SRC port %d \n", src_port);
} else {
return -4; //BINDING_SRC_DST_PORTS_FAIL
}
return 0;
}
void close_channel(void){
//close hypervisor interface
xc_interface_close(xc_handle);
//close event channel
xc_evtchn_close(xce_handle);
}
void wait_for_event(long ms){
sleep(ms);
}
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;
}
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: capturing SIGKILL in DomU 2010-10-04 19:03 capturing SIGKILL in DomU Srujan D. Kotikela @ 2010-10-05 8:36 ` Michal Novotny 2010-10-05 13:14 ` Srujan D. Kotikela 0 siblings, 1 reply; 9+ messages in thread From: Michal Novotny @ 2010-10-05 8:36 UTC (permalink / raw) To: Srujan D. Kotikela; +Cc: xen-devel 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 > http://lists.xensource.com/xen-devel > -- Michal Novotny<minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 8:36 ` Michal Novotny @ 2010-10-05 13:14 ` Srujan D. Kotikela 2010-10-05 13:22 ` Michal Novotny 0 siblings, 1 reply; 9+ messages in thread From: Srujan D. Kotikela @ 2010-10-05 13:14 UTC (permalink / raw) To: Michal Novotny; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 3072 bytes --] 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> 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 >> http://lists.xensource.com/xen-devel >> >> > > > -- > Michal Novotny<minovotn@redhat.com>, RHCE > Virtualization Team (xen userspace), Red Hat > > [-- Attachment #1.2: Type: text/html, Size: 4074 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 13:14 ` Srujan D. Kotikela @ 2010-10-05 13:22 ` Michal Novotny 2010-10-05 13:36 ` Srujan D. Kotikela 0 siblings, 1 reply; 9+ messages in thread From: Michal Novotny @ 2010-10-05 13:22 UTC (permalink / raw) To: Srujan D. Kotikela; +Cc: xen-devel 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>> 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> > http://lists.xensource.com/xen-devel > > > > -- > Michal Novotny<minovotn@redhat.com <mailto:minovotn@redhat.com>>, RHCE > Virtualization Team (xen userspace), Red Hat > > -- Michal Novotny<minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 13:22 ` Michal Novotny @ 2010-10-05 13:36 ` Srujan D. Kotikela 2010-10-05 13:49 ` Michal Novotny 0 siblings, 1 reply; 9+ messages in thread From: Srujan D. Kotikela @ 2010-10-05 13:36 UTC (permalink / raw) To: Michal Novotny; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 5068 bytes --] 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> 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>> 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> >> >> http://lists.xensource.com/xen-devel >> >> >> >> -- Michal Novotny<minovotn@redhat.com <mailto:minovotn@redhat.com>>, >> RHCE >> >> Virtualization Team (xen userspace), Red Hat >> >> >> > > -- > Michal Novotny<minovotn@redhat.com>, RHCE > Virtualization Team (xen userspace), Red Hat > > [-- Attachment #1.2: Type: text/html, Size: 6640 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 13:36 ` Srujan D. Kotikela @ 2010-10-05 13:49 ` Michal Novotny 2010-10-05 14:21 ` Srujan D. Kotikela 0 siblings, 1 reply; 9+ messages in thread From: Michal Novotny @ 2010-10-05 13:49 UTC (permalink / raw) To: Srujan D. Kotikela; +Cc: xen-devel 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>> 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>>> 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>> > > http://lists.xensource.com/xen-devel > > > > -- 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 > > -- Michal Novotny<minovotn@redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 13:49 ` Michal Novotny @ 2010-10-05 14:21 ` Srujan D. Kotikela 2010-10-05 15:33 ` Michal Novotny 0 siblings, 1 reply; 9+ messages in thread From: Srujan D. Kotikela @ 2010-10-05 14:21 UTC (permalink / raw) Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 7673 bytes --] 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> 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>> 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>>> 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>> >> >> http://lists.xensource.com/xen-devel >> >> >> >> -- 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 >> >> >> > > -- > Michal Novotny<minovotn@redhat.com>, RHCE > Virtualization Team (xen userspace), Red Hat > > [-- Attachment #1.2: Type: text/html, Size: 10276 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 14:21 ` Srujan D. Kotikela @ 2010-10-05 15:33 ` Michal Novotny 2010-10-05 23:09 ` Srujan D. Kotikela 0 siblings, 1 reply; 9+ messages in thread From: Michal Novotny @ 2010-10-05 15:33 UTC (permalink / raw) To: Srujan D. Kotikela; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: capturing SIGKILL in DomU 2010-10-05 15:33 ` Michal Novotny @ 2010-10-05 23:09 ` Srujan D. Kotikela 0 siblings, 0 replies; 9+ messages in thread From: Srujan D. Kotikela @ 2010-10-05 23:09 UTC (permalink / raw) To: Michal Novotny; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 10400 bytes --] 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@redhat.com> 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! > 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 #1.2: Type: text/html, Size: 14574 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-10-05 23:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-10-04 19:03 capturing SIGKILL in DomU Srujan D. Kotikela 2010-10-05 8:36 ` Michal Novotny 2010-10-05 13:14 ` Srujan D. Kotikela 2010-10-05 13:22 ` Michal Novotny 2010-10-05 13:36 ` Srujan D. Kotikela 2010-10-05 13:49 ` Michal Novotny 2010-10-05 14:21 ` Srujan D. Kotikela 2010-10-05 15:33 ` Michal Novotny 2010-10-05 23:09 ` Srujan D. Kotikela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.