On Wed, 2012-06-06 at 21:56 -0600, Alex Williamson wrote: > In so far as vfio should only have to call pci_reset_function and > device > quirks take care of everything else, I agree with you, but that > doesn't > answer any of my questions. Sure, we may want pre- and post-reset > fixup > quirks and a pony, but what quirk is actually necessary for this > device? > Does it fit into the existing pci_dev_specific_reset quirking? > Reloading config space isn't a good generic solution, but it might at > least shed some light on whether the reset function is doing anything > and if a simple config space change fixes it. VFIO needs to do this > anyway. Thanks, Knowing those NEC OHCI critters I suspect it just continues DMA'ing as usual and just ignores the reset... not sure what the actual setup is though, those are PCI 2.x devices behind a PCI-E to PCI-X bridge, so I'm not even sure they support a semi-decent reset. We might want to even tell the bridge to hard reset what's behind it in that case (everything is one isolation group behind that bridge anyway) but that has its own problems (CSR unreliability, need for extra delays, need to reconfigure the whole config space etc....) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
