Messages in this thread | | | Date | Tue, 08 Apr 2014 12:34:37 -0400 | From | Mark Lord <> | Subject | driver skip pci_set_master, fix it? No. |
| |
I am working a couple of drivers for chips that perform extensive bus-mastering ops. These including full SRIOV support, and allow assigning virtual functions to virtual machines, etc.
One thing the driver (still in development) does for safety, is defer the call to pci_set_master() until *after* it has mapped the MMIO space of the chips, so it can reset/flush the DMA engines before giving them permission to scribble over host RAM.
But a recent patch to the kernel has removed this from the driver's control. The core PCI now does pci_set_master() immediately on pci_enable_device().
This could be catastrophic in some situations, depending upon the state of the DMA engines in the device. If they have "leftovers" from a previous "life" (or a previous VM assignment), then they'll immediately resume accessing host RAM as soon as the driver calls pci_enable_device(), courtesy of the embedded call to pci_set_master().
This isn't good, and these may not be the only devices affected in this way.
Can we perhaps not do that, or provide some other way to return control of bus-mastering to the device driver ? -- mlord@pobox.com Mark Lord
| |