From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine Date: Sun, 02 Sep 2012 08:19:40 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Santosh Jodh , Sander Eikelenboom Cc: "wei.wang2@amd.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 02/09/2012 08:13, "Keir Fraser" wrote: > On 02/09/2012 03:08, "Santosh Jodh" 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 > >