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:13:21 +0100 Message-ID: References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4BA7@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4BA7@SJCPMAILBOX01.citrite.net> 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 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. ;-) -- Keir