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. Cheers, Ben.
