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

Hi Jean, 

At 10:47 +0100 on 16 Jun (1308221277), Jean Guyader wrote:
> We have seed such behavior when we were testing GPU assignement especially
> the Intel GPU. The problem is that domain destruction in Xen is assynchronous
> and right now the pci device reset is done in dom0 with some help of the 
> toolstack.
> 
> In the Intel GPU case we need to make sure that the guest memory and the IOMMU
> are still in place while we perform to reset otherwise the device drift into
> an unstable state.
> 
> There is probably other ways to do that in a cleaner way but we decided to 
> move
> the pci reset code into Xen, so we are sure we perform the reset while the 
> device
> is in a known state (functionning state).
> 
> Attached is the patch we have in XenClient that move the pci reset into Xen.

Thanks, Jean.  This sounds like a good idea to me, though I'd like to
hear Wei and Allen's opinions.

The patch is incomplete (missing the new pci_reset.[ch] files) but I get
the general idea.  A few questions:

 - Why the special handling for one graphics device on each domain? 
   (And if one, why not all?)
 - Why not reset when the target is dom0?  It seems like it can do no
   harm and should protect dom0 from assigning itself an active PCI
   card. 

Of course, even with this patch, my original question still stands:
should Xen do something more assertive in the IOMMU fault handler?

Cheers,

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