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