From: "Michael S. Tsirkin" <mst@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Blue Swirl <blauwirbel@gmail.com>,
Isaku Yamahata <yamahata@valinux.co.jp>,
Alexander Graf <agraf@suse.de>,
Aurelien Jarno <aurelien@aurel32.net>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Re: [PATCH 1/6] Make config space accessor host bus trapable
Date: Mon, 4 Jan 2010 23:30:21 +0200 [thread overview]
Message-ID: <20100104213021.GC21488@redhat.com> (raw)
In-Reply-To: <1262640330.2173.386.camel@pasglop>
On Tue, Jan 05, 2010 at 08:25:30AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-01-04 at 23:12 +0200, Michael S. Tsirkin wrote:
> > Well, the main issue if I understand correcttly is that basically the
> > same hardware bridge can be connected to host in different ways. Yes, we
> > can say "if it's connected differently it's a different device" but this
> > is slightly ugly, device should not have to know how it's connected. It
> > would be cleaner to have a "connector" device in the middle that swaps
> > bytes. Even though yes, what you describe would be less ugly than using
> > proprocessor as we do now.
>
> Well, the thing is... PCI is always little endian.
> I'm not 100% familiar
> on how emulation of devices works in qemu, but it's possible that the
> problem here is simply not how a standard PCI host bridge is connected
> to the processor changing but rather whether it's connected to an x86
> host or a ppc host should make the byte order appear different. IE. a
> PPC operating system will byteswap accesses. If qemu just passes on
> accesses -as-is- instead of doing natural byteswapping then indeed you
> will need that added swap there too.
>
Yes, but I think how you program your host to pci bridge is platform specific,
the standard (mostly) applies to what happens below the bridge. There's
no real standard for how PCI host bridge is connected to processor
AFAIK, it's by luck we can share code there at all.
> I still think though that this should be buried in the accessors for the
> host bridge themselves, eventually controlled by a flag set when
> instanciating the host bridge in case it can indeed be wired in
> different ways.
>
> Cheers,
> Ben.
>
buried sounds scary, but generally yes, a flag in host bridge code
is the idea.
next prev parent reply other threads:[~2010-01-05 20:02 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-03 1:50 [Qemu-devel] [PATCH 0/6] PPC NewWorld fixery Alexander Graf
2010-01-03 1:50 ` [Qemu-devel] [PATCH 1/6] Make config space accessor host bus trapable Alexander Graf
2010-01-03 15:45 ` [Qemu-devel] " Michael S. Tsirkin
2010-01-03 16:09 ` Alexander Graf
2010-01-03 17:29 ` Michael S. Tsirkin
2010-01-03 17:40 ` Alexander Graf
2010-01-03 17:44 ` Michael S. Tsirkin
2010-01-03 17:50 ` Alexander Graf
2010-01-03 18:06 ` Michael S. Tsirkin
2010-01-03 19:18 ` Blue Swirl
2010-01-10 18:41 ` Blue Swirl
2010-01-11 21:29 ` Blue Swirl
2010-01-11 22:33 ` Igor Kovalenko
2010-01-12 19:29 ` Blue Swirl
2010-01-18 19:47 ` Blue Swirl
2010-01-03 20:27 ` Alexander Graf
2010-01-03 20:50 ` Benjamin Herrenschmidt
2010-01-04 3:26 ` Alexander Graf
2010-01-04 10:45 ` Isaku Yamahata
2010-01-04 10:55 ` Alexander Graf
2010-01-04 11:08 ` Isaku Yamahata
2010-01-04 11:07 ` Michael S. Tsirkin
2010-01-04 11:13 ` Alexander Graf
2010-01-04 20:10 ` Benjamin Herrenschmidt
2010-01-04 21:12 ` Michael S. Tsirkin
2010-01-04 21:25 ` Benjamin Herrenschmidt
2010-01-04 21:30 ` Michael S. Tsirkin [this message]
2010-01-04 21:53 ` Benjamin Herrenschmidt
2010-01-04 22:25 ` Michael S. Tsirkin
2010-01-04 22:51 ` Benjamin Herrenschmidt
2010-01-04 22:59 ` Michael S. Tsirkin
2010-01-04 23:08 ` Alexander Graf
2010-01-04 23:12 ` Michael S. Tsirkin
2010-01-04 23:39 ` Benjamin Herrenschmidt
2010-01-04 23:33 ` Benjamin Herrenschmidt
2010-01-03 1:50 ` [Qemu-devel] [PATCH 2/6] Add config space conversion function for uni_north Alexander Graf
2010-01-03 15:32 ` [Qemu-devel] " Michael S. Tsirkin
2010-01-03 15:40 ` Alexander Graf
2010-01-03 15:47 ` Michael S. Tsirkin
2010-01-03 16:13 ` Alexander Graf
2010-01-03 16:20 ` Michael S. Tsirkin
2010-01-03 16:35 ` Alexander Graf
2010-01-03 17:23 ` Michael S. Tsirkin
2010-01-03 15:48 ` Michael S. Tsirkin
2010-01-03 1:50 ` [Qemu-devel] [PATCH 3/6] Use Mac99_U3 type on ppc64 Alexander Graf
2010-01-03 1:50 ` [Qemu-devel] [PATCH 4/6] Include dump of lspci -nn on real G5 Alexander Graf
2010-01-03 1:50 ` [Qemu-devel] [PATCH 5/6] Make interrupts work Alexander Graf
2010-01-03 1:50 ` [Qemu-devel] [PATCH 6/6] Enable secondary cmd64x Alexander Graf
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=20100104213021.GC21488@redhat.com \
--to=mst@redhat.com \
--cc=agraf@suse.de \
--cc=aurelien@aurel32.net \
--cc=benh@kernel.crashing.org \
--cc=blauwirbel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).