On Thu, 22 Mar 2018 21:09:09 +0000 Casey Leedom <leedom@xxxxxxxxxxx> wrote: > | From: Alex Williamson <alex.williamson@xxxxxxxxxx> > | Sent: Thursday, March 22, 2018 6:13 AM > | ... > | On Thu, 22 Mar 2018 18:32:56 +1100 > | Alexey Kardashevskiy <aik@xxxxxxxxx> wrote: > | > ... > | > No, I do not want to block INTx and I am happy with "[PATCH v2] > | > vfio/pci: Quiet broken INTx whining when INTx is unsupported by > | > device". I am missing the point here, sorry, no-INTx-routing + > | > no-DisINTx + no-MSI(X) - I understand why we would want to block > | > these but if a device cannot do INTx nicely but still can do > | > MSI(X) - why would we want to block it? > | > | Because "cannot do INTx nicely" means one of: > | > | a) device can assert INTx all it wants and nobody cares (ie. it's not > | connected or routed) > | > | b) device INTx is connected or routed at the pHyp level, the device can > | cause badness by asserting INTx, we are only advising the user not to > | use INTx > | > | The assumption in my version of the patch is a), but you seem to have > | clarified that the situation is really b), in which case we have no > | solution for devices which do not support DisINTx, they should be > | disallowed from use through vfio. The user has the ability to cause > | the device to assert INTx regardless of whether we report a pin > | register, report INTx irq info, or support it through SET_IRQ, it > | cannot be masked at the device, the pHyp hypervisor has not provided > | routing, so it cannot be masked at an interrupt controller, and > | apparently we cannot presume that asserting INTx is harmless, as I'd > | hoped. What prevents a user from exploiting INTx on a device that does > | not support DisINTx when running on pHyp? Thanks, > > I must remind everyone that Single Root I/O Virtualization Virtual Functions > may _NOT_ implement Legacy Pin INTx Interrupts as per the SR-IOV > specification. I.e. VFs cannot and must not implement INTx ... and they That's not the under debate, VFs are fine, they cannot assert INTx, the original commit was never intended to affect them. The question is on this pHyp platform where we might be assigning a traditional PCIe endpoint where the device does support INTx, but the hypervisor (which we're running on) is not exposing INTx routing, therefore we have an INTx pin, but we don't have pdev->irq and we need to guess whether the device asserting INTx can cause bad things. If we think the device supports DisINTx, we can limit it's ability to assert INTx, if not, the user can make the device assert INTx regardless of what we expose to it. > were the entire original motivation for allowing PCI Devices to be attached > to Virtual Machines ... That's debatable. Obviously aspects of VFs make them much preferred for assignment, but device assignment would be here with or without them and we get to deal with supporting all flavors of devices. Thanks, Alex
