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: paul@codesourcery.com, 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 18:47:31 +0300	[thread overview]
Message-ID: <20110720154731.GA8077@redhat.com> (raw)
In-Reply-To: <4E26E803.8040408@siemens.com>

On Wed, Jul 20, 2011 at 04:36:51PM +0200, Jan Kiszka wrote:
> > A 4 byte access at address 255 would wrap around to 0 with this,
> > while previously we ignored high bits on write and returned
> > 0 on read.
> 
> The question is rather what the spec or real hw demand from us. Do you
> have any insights on this? I didn't find hints which behavior is more
> compliant. It looks like such access patterns are deep into bug land anyway.

For the express side, we don't need to support accesses that cross a 4
byte boundary - but guests might be able to generate them.
Just in case, I'd prefer keeping the current behaviour WRT that.
Paul, do you know which guests can do this?

However, as far as I can tell accesses within a dword can have
any bytes enabled. So our interface for passing that info to
devices isn't all that good, and I'm not 100% sure splitting
up to length aligned transactions is better.
Maybe passing in a byte_enable mask is a better idea.


For example, as far as I an tell sysfs let you write/read
any length (it splits it up internally ATM) so
it seems somewhat useless to do that work in
userspace as well.
We will, however, have to see how does the code look in the end.



-- 
MST

      reply	other threads:[~2011-07-20 15:47 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
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 [this message]

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=20110720154731.GA8077@redhat.com \
    --to=mst@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /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.