All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.