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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Saturday, September 1, 2012, 9:13:17 PM, you wrote:

> 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.

Are there any printk's I could add to get more relevant info about the AMD-Vi: 
IO_PAGE_FAULT ?

I have attached new output from xl dmesg, this time with iommu=debug on (the 
option changed from 4.1 to 4.2).



>  -- Keir

Attachment: xl-dmesg.txt
Description: Text document

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