From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjdBy-0007JS-Bj for qemu-devel@nongnu.org; Wed, 20 Jul 2011 16:16:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjdBv-0001ZU-TD for qemu-devel@nongnu.org; Wed, 20 Jul 2011 16:16:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjdBv-0001ZI-6b for qemu-devel@nongnu.org; Wed, 20 Jul 2011 16:16:23 -0400 Date: Wed, 20 Jul 2011 23:16:49 +0300 From: "Michael S. Tsirkin" Message-ID: <20110720201649.GA11238@redhat.com> References: <4E25F976.8010200@web.de> <20110720120027.GI3699@valinux.co.jp> <4E26C6C5.3060505@siemens.com> <4E26E5BC.6040508@siemens.com> <20110720161702.GL3699@valinux.co.jp> <4E26FFE3.5060909@siemens.com> <20110720164521.GF8077@redhat.com> <4E270C21.9050008@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E270C21.9050008@siemens.com> Subject: Re: [Qemu-devel] [PATCH] pci: Length-align config space accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Isaku Yamahata , qemu-devel , Avi Kivity On Wed, Jul 20, 2011 at 07:10:57PM +0200, Jan Kiszka wrote: > On 2011-07-20 18:45, Michael S. Tsirkin wrote: > > On Wed, Jul 20, 2011 at 06:18:43PM +0200, Jan Kiszka wrote: > >> On 2011-07-20 18:17, Isaku Yamahata wrote: > >>> On Wed, Jul 20, 2011 at 04:27:08PM +0200, Jan Kiszka wrote: > >>>> On 2011-07-20 14:15, Jan Kiszka wrote: > >>>>> On 2011-07-20 14:00, Isaku Yamahata wrote: > >>>>>> Hi. This clean up looks good basically. > >>>>> > >>>>> Oops, forgot to cc you. Sorry. > >>>>> > >>>>>> But when conventional pci device is accessed via MMCONFIG area, > >>>>>> addr &= addr_mask doesn't work as expected. > >>>>>> The config area of [256, 4K) of conventional pci should have no effect. > >>>>> > >>>>> Mmh, I see. Looks like we need to split accesses at this boundary and > >>>>> executed them separately. > >>>> > >>>> Nope, no such issue: we already automatically split up accesses that > >>>> span the legacy/extended boundary. Just like so far, legacy config space > >>>> handlers have to filter out requests that address regions >= 256. > >>> > >>> For example, when accessing to offset 257 of conventional pci device, > >>> the access is routed to offset 1 due to the masking. > >>> Such overwrapping isn't correct. > >> > >> No, it isn't routed like that. The mask used via mmio is 0xfff. > >> > >> Jan > > > > I thought about this some more, I'd like to see how devices > > are going to benefit. Any examples? > > No in-tree device currently gets beyond the "write default, check range" > pattern. > > > If not, is it easier to simply make this logic > > part of dev assignment? > > That's a question of clean interfaces. Not checking at the core means > exposing invalid accesses to the callbacks. That's the point: at least the express spec seems to explicitly allow any accesses within a dword, and disallow accesses crossing dwords. And there's no way to create such on the PCI bus either. So it makes sense to handle cross-dword accesses in a special way (possibly disallow them altogether, need to check non-pc systems for this). But non-aligned access within a dword is legal according to the spec. > The logic is required anyway, so better put it in a central place. E.g. > if the Xen people push their device assignment as well, we will suddenly > have more than one user. > > Jan That's the question: why is the logic required? -- MST