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: Sat, 01 Sep 2012 20:13:17 +0100 Message-ID: References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@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 01/09/2012 18:03, "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? >> >> Well, anyway, I don't know how useful a massive dump of the entire p2m is >> going to be for debugging anyway. If investigating an IOMMU page fault, I'd >> just want the info pertaining to that fault, and all the mapping information >> for >> that IO virtual address, dumped. :) > > It is not a generically useful command - its usefulness is in the same > category as dumping the MMU table. Unfortunately, there is no way to pass > arguments to the key handler - to say provide the VM and or starting gfn and > length for a more selective output. Quite simply, there likely needs to be more tracing on the IOMMU fault path. That's a separate concern from your keyhandler of course, but just saying I'd be looking for the former rather than the latter, for diagnosing Sander's bug. -- Keir