Re: [Xen-devel] RUNSTATE_runnable delta time for idle_domain accounted to HVM guest.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.05.14 at 19:36, <konrad.wilk@xxxxxxxxxx> wrote:
> The reason we schedule a tasklet instead of continuing with an
> 'vcpu_kick' is not yet known to me. This commit added the mechanism
> to do it via the tasklet:
> 
> commit a5db2986d47fafc5e62f992616f057bfa43015d9
> Author: Keir Fraser <keir.fraser@xxxxxxxxxx>
> Date:   Fri May 8 11:50:12 2009 +0100
> 
>     x86 hvm: hvm_set_callback_irq_level() must not be called in IRQ
>     context or with IRQs disabled. Ensure this by deferring to tasklet
>     (softirq) context if required.
>     
>     Signed-off-by: Keir Fraser <keir.fraser@xxxxxxxxxx>
> 
> But I am not sure why:
> 
>  a). 'must not be called in IRQ context or with IRQs disabled' is
>     important - I haven't dug in the code yet to understand the
>     crucial reasons for - is there a known issue about this?

Because of its use of spin_lock(), which would have the potential
for a deadlock if the function was called in the wrong context. The
apparent alternative would be to make all users of
d->arch.hvm_domain.irq_lock use the IRQ-safe variant; I didn't
check whether that would in turn cause new problems.

>  b). Why do we have a per-cpu tasklet lists, but any manipulation of the
>      items of them are protected by a global lock. Looking at the code in
>      Linux and Xen the major difference is that Xen can schedule on specific 
> CPUs
>      (or even the tasklet can schedule itself on another CPU).

tasklet_kill() and migrate_tasklets_from_cpu() at the very least
would need very careful modification if you were to replace the
global lock.

>      I can see the need for the tasklets being on different CPUs for
>      the microcode, and I am digging through the other ones to get
>      a feel for it - but has anybody thought about improving this
>      code? Has there been any suggestions/ideas tossed around in the
>      past (the mailing list didn't help or my Google-fun sucks).

I'm not aware of any such, quite likely because no-one so far
spotted a problem with the current implementation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel