All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Isaku Yamahata <yamahata@valinux.co.jp>,
	qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pci: Length-align config space accesses
Date: Wed, 20 Jul 2011 23:16:49 +0300	[thread overview]
Message-ID: <20110720201649.GA11238@redhat.com> (raw)
In-Reply-To: <4E270C21.9050008@siemens.com>

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

  reply	other threads:[~2011-07-20 20:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-19 21:39 [Qemu-devel] [PATCH] pci: Length-align config space accesses Jan Kiszka
2011-07-20 12:00 ` Isaku Yamahata
2011-07-20 12:15   ` Jan Kiszka
2011-07-20 14:27     ` Jan Kiszka
2011-07-20 16:17       ` Isaku Yamahata
2011-07-20 16:18         ` Jan Kiszka
2011-07-20 16:33           ` Isaku Yamahata
2011-07-20 16:45           ` Michael S. Tsirkin
2011-07-20 17:10             ` Jan Kiszka
2011-07-20 20:16               ` Michael S. Tsirkin [this message]
2011-07-20 16:19         ` Michael S. Tsirkin
2011-07-20 14:22 ` Michael S. Tsirkin
2011-07-20 14:36   ` Jan Kiszka
2011-07-20 15:47     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110720201649.GA11238@redhat.com \
    --to=mst@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yamahata@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.