From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Anthony Liguori" <aliguori@us.ibm.com>,
"Marcel Apfelbaum" <marcel.a@redhat.com>,
"Jan Kiszka" <jan.kiszka@siemens.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort
Date: Mon, 16 Sep 2013 00:07:24 +0300 [thread overview]
Message-ID: <20130915210724.GA7975@redhat.com> (raw)
In-Reply-To: <CAFEAcA_GeGvTm+kAt=9c9yqxH49jMnA9=V_ReN=OpEC+TxX=jg@mail.gmail.com>
On Sun, Sep 15, 2013 at 09:40:37PM +0100, Peter Maydell wrote:
> On 15 September 2013 21:25, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Sun, Sep 15, 2013 at 06:32:13PM +0100, Peter Maydell wrote:
> >> On 15 September 2013 18:30, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Sun, Sep 15, 2013 at 07:16:41PM +0300, Marcel Apfelbaum wrote:
> >> >> +static const MemoryRegionOps master_abort_mem_ops = {
> >> >> + .read = master_abort_mem_read,
> >> >> + .write = master_abort_mem_write,
> >> >> + .endianness = DEVICE_NATIVE_ENDIAN,
> >> >> +};
> >> >> +
> >> >
> >> > Please make it little endian.
> >> > DEVICE_NATIVE_ENDIAN is almost always a bug.
> >>
> >> ...when dealing with PCI devices. For a random device on the system bus
> >> it's often correct.
>
> > native is really qemu host endian-ness ... what are some
> > examples when it's actually correct?
>
> "native" means "if the device's MMIO callback does 'return 0x12345678;'
> for a 32 bit read then the guest CPU should see 0x12345678". That's
> almost always what you want for simple devices (which may in fact
> only support 32 bit accesses to registers), because it means you don't
> have to fill your device with explicit endianness swaps.
But this means that you device behaves differently
depending on the endian-ness of the guest system.
So it only makes sense if the device is very
system specific: anything outside hw/<specific architecture>
is at least in theory not a system specific device so
it should not do this.
> It's also useful
> if that kind of simple device might be built into either a little endian
> or a bigendian system: as far as the device is concerned its 32 bit
> registers still have (say) the TXRDY bit at the low end of the status
> register even if the CPU is bigendian.
>
> That said, our current setup of marking the mmio ops with an endianness
> is really conflating what in real hardware is a number of distinct properties
> of the CPU, the bus, any bus controllers (like PCI!) in the path between
> CPU and device and finally the device itself. So it's inherently both
> confusing and confused.
>
> -- PMM
next prev parent reply other threads:[~2013-09-15 21:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-15 16:16 [Qemu-devel] [PATCH v4 0/3] pci: implement upstream master abort protocol Marcel Apfelbaum
2013-09-15 16:16 ` [Qemu-devel] [PATCH v4 1/3] memory: allow MemoryRegion's priority field to accept negative values Marcel Apfelbaum
2013-09-15 17:18 ` Michael S. Tsirkin
2013-09-15 17:25 ` Peter Maydell
2013-09-15 17:34 ` Peter Maydell
2013-09-15 16:16 ` [Qemu-devel] [PATCH v4 2/3] docs/memory: Explicitly state that MemoryRegion priority is signed Marcel Apfelbaum
2013-09-15 17:33 ` Peter Maydell
2013-09-15 16:16 ` [Qemu-devel] [PATCH v4 3/3] hw/pci: handle downstream pci master abort Marcel Apfelbaum
2013-09-15 17:30 ` Michael S. Tsirkin
2013-09-15 17:32 ` Peter Maydell
2013-09-15 18:32 ` Marcel Apfelbaum
2013-09-15 20:25 ` Michael S. Tsirkin
2013-09-15 20:40 ` Peter Maydell
2013-09-15 21:07 ` Michael S. Tsirkin [this message]
2013-09-15 21:41 ` Peter Maydell
2013-09-16 6:14 ` Michael S. Tsirkin
2013-09-16 6:57 ` Peter Maydell
2013-09-15 18:26 ` Marcel Apfelbaum
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=20130915210724.GA7975@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=marcel.a@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--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 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).