[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] capturing SIGKILL in DomU
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@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.
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>
<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
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>>
<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
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>>
<mailto: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>>
<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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
--
Michal Novotny<minovotn@xxxxxxxxxx>, RHCE
Virtualization Team (xen userspace), Red Hat
Attachment:
xswatchtest.c
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
