Re: [Xen-devel] Re: IOMMU faults

[Jean Guyader <jean.guyader@xxxxxxxxxxxxx>]

On 30/06 11:08, Tim Deegan wrote:
> At 14:32 +0100 on 24 Jun (1308925934), Tim Deegan wrote:
> > At 11:28 +0100 on 16 Jun (1308223697), Jean Guyader wrote:
> > > > Of course, even with this patch, my original question still stands:
> > > > should Xen do something more assertive in the IOMMU fault handler?
> > > 
> > > What we really want to achive here is to stop DMA on this device.
> > > One way of doing it is to perform a proper PCI reset (FLR, secondary
> > > bus reset, ...) when that happens.
> > 
> > I think that's more or less a consensus then, that we should try to
> > stop the device from the IOMMU fault handler.
> > 
> > Looking at your patch in a bit more detail, I see two things that worry
> > me.  The first is that the new pci_reset_device() function does nothing
> > at all if the device isn't one of the particular graphics cards it know
> > about!
> > 

In our case the reset of other devices is done using the classic Xen toolstack
way in dom0. But the code could be easily changed to do a proper reset on all
the type of devices.


> > The second is this comment: 
> > 
> > > +    /* Leave CMD MEMORY set otherwise the platform can crashe during FLR 
> > > */
> > > +    pci_conf_write16(bus, d, f, PCI_COMMAND, 2);
> > 
> > which implies that my current approach of just disabling the card might
> > have pretty bad conequences.  Can you expand on that?  Would it be
> > better just to mask out PCI_COMMAND_MASTER?  And if I do that do I need
> > to try and issue a reset as well (i.e. are there cards that are known to
> > ignore this bit?)

Agreed, masking out PCI_COMMAND_MASTER should be enough, Linux only do that.

Jean

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