On Mon, Jun 23, 2014 at 11:13:45PM +0200, Alexander Graf wrote: > >> Am 23.06.2014 um 23:03 schrieb Benjamin Herrenschmidt >> <b...@kernel.crashing.org>: >> >>> On Mon, 2014-06-23 at 18:18 +0200, Alexander Graf wrote: >>> Device emulation code shouldn't even remotely have an idea what host >>> it's running on. Also semantically there are a few issues with this approach >>> >>> 1) QEMU is usually running with user privileges, so it doesn't have >>> access to the file above >> >> Right, this needs to go via VFIO like the rest of the EEH stuff >> >>> 2) QEMU's channel to hardware devices is via normal kernel API. For >>> physical devices that's VFIO. No side channels please. >> >> Indeed. If the user gets access to that file, suddenly qemu can >> "manufacture" a bad string and error inject in other devices it doesn't >> own which isn't great. >> >> Gavin, this needs to go via the same path as normal EEH and be limited >> to injecting errors that are completely bounded to the PE. >> >> I don't think this is very high priority. We should first write a good >> host side error injection tool and sort out the reporting of the EEH log >> from host to guest. >> >>> 3) Ownership of the question whether a PE is in error mode is >>> responsibility of the PHB. In the emulated case, the PHB would have to >>> set itself into a mode where it behaves as if it's blocked. >> >> We don't have to support error injection for emulated since we don't >> support (yet) the rest oF EEH for them. We could one day but it's >> really not urgent. > >I agree, but the layers are the same ;) >
Thanks, Ben and Alex. Yes, it's fair enough for VFIO (ioctl cmd) to routing the PCI error injection. Thanks, Gavin >Alex > >> >> Cheers, >> Ben. >>
