From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzBPP-000244-TL for qemu-devel@nongnu.org; Mon, 23 Jun 2014 17:04:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzBPJ-0004JC-Bk for qemu-devel@nongnu.org; Mon, 23 Jun 2014 17:04:11 -0400 Received: from gate.crashing.org ([63.228.1.57]:57139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzBPJ-0004In-2R for qemu-devel@nongnu.org; Mon, 23 Jun 2014 17:04:05 -0400 Message-ID: <1403557434.4587.134.camel@pasglop> From: Benjamin Herrenschmidt Date: Tue, 24 Jun 2014 07:03:54 +1000 In-Reply-To: <53A8535D.1080209@suse.de> References: <1403490123-15969-1-git-send-email-gwshan@linux.vnet.ibm.com> <1403490123-15969-2-git-send-email-gwshan@linux.vnet.ibm.com> <53A8535D.1080209@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 1/3] sPAPR: Implement PCI error injection RTAS calls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: aik@ozlabs.ru, qiudayu@linux.vnet.ibm.com, Gavin Shan , qemu-devel@nongnu.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. Cheers, Ben.