From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2gAQ-0006Iv-CQ for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:35:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2gAM-00088v-Bw for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:35:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2gAM-00088j-6d for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:35:38 -0400 Date: Wed, 10 Jun 2015 15:35:33 +0200 From: "Michael S. Tsirkin" Message-ID: <20150610153050-mutt-send-email-mst@redhat.com> References: <20150607082252-mutt-send-email-mst@redhat.com> <557563A10200007800081D1F@mail.emea.novell.com> <55754DAB.2070102@citrix.com> <557576760200007800081DC8@mail.emea.novell.com> <20150608113130-mutt-send-email-mst@redhat.com> <557590BA020000780008201C@mail.emea.novell.com> <20150608131214-mutt-send-email-mst@redhat.com> <5577FCC70200007800082E51@mail.emea.novell.com> <20150610134158-mutt-send-email-mst@redhat.com> <5578446302000078000830BE@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5578446302000078000830BE@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: xen-devel@lists.xensource.com, pmatouse@redhat.com, Stefano Stabellini , Andrew Cooper , qemu-devel@nongnu.org, Malcolm Crossley On Wed, Jun 10, 2015 at 01:06:27PM +0100, Jan Beulich wrote: > >>> On 10.06.15 at 13:43, wrote: > > On Wed, Jun 10, 2015 at 08:00:55AM +0100, Jan Beulich wrote: > >> >>> On 08.06.15 at 13:28, wrote: > >> > On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote: > >> >> while function 0 has > >> >> > >> >> 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access, prefetchable) > >> >> 0x18: Base Address Register 2 = 0xca24000c (Memory space, 64-bit access, prefetchable) > >> >> 0x20: Base Address Register 4 = 0xca25000c (Memory space, 64-bit access, prefetchable) > >> >> > >> >> and function 1 > >> >> > >> >> 0x10: Base Address Register 0 = 0xca20000c (Memory space, 64-bit access, prefetchable) > >> >> 0x18: Base Address Register 2 = 0xca21000c (Memory space, 64-bit access, prefetchable) > >> >> 0x20: Base Address Register 4 = 0xca22000c (Memory space, 64-bit access, prefetchable) > >> >> > >> >> > Does the sibling device have a BAR overlapping the address? > >> >> > >> >> No, its BARs are fully separate. > >> > > >> > Judging from the above, it's actually function 1's BAR 2 that > >> > is accessed? Are you saying disabling memory on function 0 > >> > breaks function 2 somehow? > >> > >> Oops, just noticed I didn't reply to this. Not sure how you > >> come to that conclusion - the ITP log says that the bad write is to > >> 0xca25004c. > > > > Look at the bridge configuration though - looks like it > > will only forward transactions to 0xca21XXXX. > > Anything else will be terminated by the bridge itself. > > Right, that's what I had pointed out before, but then again things > work prior to the guest shutting down (and in the absence of any > guest), even if I can't explain why or how. > > Jan I have a wild idea. Maybe there's a chance function 1 sends the offending write to 0xca25000c, then gets confused and crashes if that fails? -- MST