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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 01/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@xxxxxxxxxx> 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



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