From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Novotny Subject: Re: capturing SIGKILL in DomU Date: Tue, 05 Oct 2010 15:49:53 +0200 Message-ID: <4CAB2D01.9010106@redhat.com> References: <4CAAE39C.1020708@redhat.com> <4CAB26AA.6040300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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