Problems with hypercalls

[Peter Teoh]

I guessed the cause of the error is really somewhere else - nothing to
do with this part.   But without a full view of the entire source - it
is hard to diagnose the bugs. (Perhaps even more difficult if full
view is available).   But I have no problem insmod lg.ko in
drivers/lguest directory (after CONFIG_LGUEST is set to "m"), and
lguest is not a simple example I must say.   And to get a better
understanding on how to use the kvm_hypercall APIs, just go to the
kernel source's drivers/lguest directory and enter "make" and it will
churns lots of information (totalling about 7000+ lines) teaching you
the basic of KVM - both how the KVM hypervisor works, and how the
lguest work.

And if u are lazy to do a "make" this is my version:

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B1hg6_FvnEa8ZjFjMDQxNzAtZDAyZC00MDA2LTk3YmMtNGE5YjdjZDM0Nzc3&hl=en_US

On Thu, Jun 9, 2011 at 4:35 PM, emilie lefebvre <tricheurs at hotmail.fr> wrote:
> Hi,
> I try this :
>
>  local_irq_save(flags);
>  kvm_hypercall2 ( 6, 2, 2);
>  local_irq_restore(flags);
>
> But I still have my kernel panic with "divide error: 0000 [#1] SMP" that I
> don't understand!
> with or without lock, nothing change, the same when I change the current
> state.
>
> I tried to move my hypercall and I still don't understand why it works just
> before my test
> "if (piga_on == 1)" without any protections (like disable interrupts) and
> not after..
>
> Thank you for trying to help me
>
>
>> Date: Thu, 9 Jun 2011 09:46:12 +0800
>> Subject: Re: Problems with hypercalls
>> From: htmldeveloper at gmail.com
>> To: tricheurs at hotmail.fr
>> CC: kernelnewbies at kernelnewbies.org
>>
>> perhaps this example will provide u with more info:
>>
>> http://a380.informatik.uni-bremen.de/lxr/source/arch/x86/lguest/boot.c
>>
>> I think the correct step is to disable IRQ instead - before every call
>> to kvm_hypercallX(). The reason is given in the remark:
>>
>> 110 /*
>> 111 * Disable interrupts if not already disabled: we don't want an
>> 112 * interrupt handler making a hypercall while we're already doing
>> 113 * one!
>> 114 */
>>
>> On Wed, Jun 8, 2011 at 10:54 PM, emilie lefebvre <tricheurs at hotmail.fr>
>> wrote:
>> >
>> > This is my function :
>> >
>> > static spinlock_t xgr_learn_lock = SPIN_LOCK_UNLOCKED;
>> > static int piga_seq_cpt = 1;
>> >
>> > /*
>> > * Function called for each systemcall (Hook SELinux avc function)
>> > */
>> > int piga_control(u32 ssid, ...., struct av_decision * avd) {
>> >
>> > /*
>> > * Here my hypercall work but block my vm with this error :
>> > *                " BUG: scheduling while atomic ... "
>> > */
>> >
>> > spin_lock_bh(&xgr_learn_lock);
>> >   if ( in_atomic())
>> >            kvm_hypercall2 ( 6, (unsigned long)2 ,(unsigned
>> > long)piga_seq_cpt);
>> >   spin_unlock_bh(&xgr_learn_lock);
>> >
>> >  if (piga_on == 1) {
>> > /*
>> > * Here my hypercall make a kernel panic with this error:
>> > *             " divide error: 0000 [#1] SMP"
>> > */
>> >                 spin_lock_bh(&xgr_learn_lock);
>> >                 set_current_state(TASK_UNINTERRUPTIBLE);
>> >                 kvm_hypercall2 ( 6, (unsigned long)2 ,(unsigned
>> > long)piga_seq_cpt);
>> >                 set_current_state(TASK_RUNNING);
>> >                 spin_lock_bh(&xgr_learn_lock);
>> > }
>> > }
>> >
>> >
>>
>> I think u generally set TASK_UNINTERRUPTIBLE whenever about to modify
>> the scheduling task list (eg, wait queue manipulation) or about to
>> call "schedule()" (ie, doing your own scheduling). The function
>> set_current_state() literally just set the variable value only, it
>> does not disable interrupt.
>>
>> --
>> Regards,
>> Peter Teoh
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>



-- 
Regards,
Peter Teoh