WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RE: IOMMU faults

At 12:21 -0700 on 16 Jun (1308226873), Kay, Allen M wrote:
> > - The Intel IOMMU fault handler prints quite a lot of info in interrupt
> >   context, making it easier to livelock.  Still I think the general
> >   problem applies on AMD too.
> 
> Someone at Intel looked into implementing measured rate printing in vt-d 
> fault handler.  He encountered some complications.  I remember it had to do 
> with measured rate printing not enabled by default (?).  For now, I think 
> having it print out only for debug case sounds simple enough.  I will submit 
> a patch for it.
> 

That's great, thanks. 

> > - Domain destruction re-assigns passed though cards to dom0, but the
> >   cards don't seem to get reset.  So there's nothing to stop a card
> >   battering away at DMA in the meantime.  That seems like a problem
> >   independent of livelock, actually.
> 
> >From reading the code in libxl, it seems libxl__device_pci_reset() is called 
> >by both libxl__device_pci_add() and do_pci_remove().  Isn't do_pci_remove() 
> >called when the pass through device is reassigned to dom0 during a domain 
> >teardown?

Libxl could be too late, though.  When a domain is destroyed, its iommu
tables get torn down in Xen.  So if it has active devices:
 - they can start raising IOMMU faults immediately, and in some
   circumstances libxl might never get to run. 
 - since deassign is implemented as "assign to dom0" they might start 
   DMAing over dom0 memory.
If we can rely on the dom0 tools always completely resetting a domains's
devices before calling domctl_destroydomain, that should never happen.
That seems a bit fragile, though I guess dom0 can shoot itself in the foot in
enough other ways.   I prefer Jean's reset-in-xen approach; it's only a few
hundred lines of code and we could reuse some of it for resetting
badly-behaved cards from the IOMMU fault handler. 

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>