Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine

[Keir Fraser <keir.xen@gmail.com>]

On 02/09/2012 08:13, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 02/09/2012 03:08, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:
> 
>>>>> It might schedule softirqs but that won't include scheduling or
>>>>> running any guest vcpus. The vcpu that happens to be running on that
>>>>> cpu at the time the debug dump starts, will be stuck unrunnable until the
>>> dump completes.
>>>> 
>>>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
>>>> way to yield the CPU from the key handler?
>>> 
>>> It can't be descheduled from this pCPU without running through the
>>> scheduler. You could try running the handler in a tasklet -- a tasklet
>>> causes
>>> other vCPUs to be descheduled from that pCPU, before it starts running.
>>> 
>>> So you'd register a keyhandler which does a tasklet_schedule(), and do your
>>> logging work in the tasklet handler.
>>> 
>>> Worth a shot maybe?
>> 
>> Yes - certainly. Is there a reason why all key handlers should not be
>> tasklets?
> 
> Some keys you want to print immediately (stack trace), or you are using them
> when the system is in a bad way, and deferring the tracing may cause you to
> get no tracing at all. There may be a few informational keys, for irqs and
> the like, that could be moved to tasklet context though, yes. It's just the
> tasklet-in-hypervisor-thread mechanism is newer than the key handlers. ;-)

Actually, ignore me, most keyhandlers are getting deferred to a tasklet
context already. At least when triggered from a serial irq. See
common/keyhandler.c:handle_keypress().

So your handler, when triggered by 'o' over the serial line, will be running
in tasklet context already. So vCPU execution is getting stalled just
because, I'm not sure, not running through the scheduler softirq for ages on
that pCPU is maybe confusing the scheduler? :(

 -- Ker

>  -- Keir
> 
>