| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: IOMMU faults
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
|
|
|
| |
|
Home