From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2eSk-0005Wq-3i for qemu-devel@nongnu.org; Wed, 10 Jun 2015 07:46:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2eSg-0006Bl-MI for qemu-devel@nongnu.org; Wed, 10 Jun 2015 07:46:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2eSg-0006Be-Gg for qemu-devel@nongnu.org; Wed, 10 Jun 2015 07:46:26 -0400 Date: Wed, 10 Jun 2015 13:46:22 +0200 From: "Michael S. Tsirkin" Message-ID: <20150610134414-mutt-send-email-mst@redhat.com> References: <552BD57B0200007800071763@mail.emea.novell.com> <20150413144223-mutt-send-email-mst@redhat.com> <552BD7DA0200007800071783@mail.emea.novell.com> <20150420153915-mutt-send-email-mst@redhat.com> <553524690200007800073D57@mail.emea.novell.com> <20150420162712-mutt-send-email-mst@redhat.com> <20150607082252-mutt-send-email-mst@redhat.com> <557563A10200007800081D1F@mail.emea.novell.com> <20150608110120-mutt-send-email-mst@redhat.com> <5577FE950200007800082E64@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5577FE950200007800082E64@mail.emea.novell.com> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xensource.com, pmatouse@redhat.com, qemu-devel@nongnu.org, Stefano Stabellini On Wed, Jun 10, 2015 at 08:08:37AM +0100, Jan Beulich wrote: > >>> On 08.06.15 at 11:30, wrote: > > What happens if you disable SERR# in the command register > > of 83:00.1? > > We've just been told that with SERR not enabled in any of the > sibling endpoints the NMI still occurs. Not really surprising with > us now assuming that it's the root port that generates the SERR > in response to the UR coming back from an endpoint. But otoh > in conflict with what we see in the ITP log (where SERR clearly > is enabled on the endpoints, and the information we got says > that it _is_ disabled, not that they had to do anything to disable > it). > > > 2. Has a driver initialized this endpoint? What if you don't > > load a driver before sending the transaction resulting in the UR? > > They now tried at least without loading a driver in Dom0, which > didn't make a difference. Did you mean to also not load any driver > in the guest? Otoh I can't really see what difference this makes, > as the cleanup after the guest inside the hypervisor doesn't > really depend much on whether it actively used any of the MSI-X > entries. > > Jan I don't really know. The idea would be that device is not designed for memory to be disabled when it's active, and starts behaving in broken ways. -- MST