qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Rusty Russell <rusty@rustcorp.com.au>,
	"Daniel P. Berrange" <berrange@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Andreas Färber" <afaerber@suse.de>,
	anton@samba.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access
Date: Fri, 09 Aug 2013 09:16:18 -0500	[thread overview]
Message-ID: <8738qjlzkd.fsf@codemonkey.ws> (raw)
In-Reply-To: <87vc3fo9j1.fsf@rustcorp.com.au>

Rusty Russell <rusty@rustcorp.com.au> writes:

> Anthony Liguori <anthony@codemonkey.ws> writes:
>> "Daniel P. Berrange" <berrange@redhat.com> writes:
>>
>> The distinction is important in QEMU.  ppc64 is still
>> TARGET_WORDS_BIGENDIAN.  We still want most stl_phys to treat integers
>> as big endian.  There's just this extra concept that CPU loads/stores
>> are sometimes byte swapped.  That affects virtio but not a lot else.
>
> You've redefined endian here; please don't do that.  Endian is the order
> in memory which a CPU does loads and stores.  From any reasonable
> definition, PPC is bi-endian.
>
> It's actually a weird thing for the qemu core to know at all: almost
> everything which cares is in target-specific code.  The exceptions are
> gdb stubs and virtio, both of which are "native endian" (and that weird
> code in exec.c: what is notdirty_mem_write?).
>
> Your argument that we shouldn't fix stl_* might be justifiable (ie. just
> hack virtio and gdb as one-offs), but it's neither clear nor "least
> surprise".

That's not what I'm suggesting.

I'm suggesting that we should introduce multiple variants of {ld,st}*
for different types of memory access.

These are bad names, but I'm thinking along the lines of:

/* Read a word as the load/store instructions would */
cpu_ldst_ldw()

/* Read a word as the instruction fetch unit would */
cpu_fetch_ldw()

/* Read a word as the hardware MMU would */
cpu_mmu_ldw()

Peter was suggesting that instead of having separate functions, we
should use a context:

ldw(cpu->ldst, ..)
ldw(cpu->fetch, ..)
...

I think I prefer functions though over a context.  But this is really
about TCG, not virtio.  As Ben pointed out, virtio endianness needs to
be independent of CPUs.  We process the ring outside of a specific CPU
context and it's possible that if we pick an arbitrary one, it will be
in the wrong context (if running BE userspace).

The only real problem I have with your original patch is putting virtio
knowledge in the target code.  I think your adjusted version is fine.

Regards,

Anthony Liguori

>
> Chers,
> Rusty.

  parent reply	other threads:[~2013-08-09 14:16 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08  5:15 [Qemu-devel] [PATCH 0/7] Virtio support for endian-curious guests Rusty Russell
2013-08-08  5:15 ` [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access Rusty Russell
2013-08-08 13:31   ` Anthony Liguori
2013-08-08 14:28     ` Andreas Färber
2013-08-08 15:40       ` Anthony Liguori
2013-08-08 15:45         ` Daniel P. Berrange
2013-08-08 16:07           ` Anthony Liguori
2013-08-08 16:14             ` Peter Maydell
2013-08-08 16:25               ` Anthony Liguori
2013-08-08 16:30                 ` Peter Maydell
2013-08-09  2:58             ` Rusty Russell
2013-08-09  4:39               ` Anton Blanchard
2013-08-09  8:05               ` Peter Maydell
2013-08-09 14:16               ` Anthony Liguori [this message]
2013-08-08 15:48         ` Peter Maydell
2013-08-08 16:11           ` Anthony Liguori
2013-08-08 16:24         ` Andreas Färber
2013-08-09  7:35           ` Rusty Russell
2013-08-09  7:42             ` Peter Maydell
2013-08-12  7:49               ` Rusty Russell
2013-08-09  7:49             ` Benjamin Herrenschmidt
2013-08-12  0:28               ` Rusty Russell
2013-08-12  0:49                 ` Benjamin Herrenschmidt
2013-08-09 15:15             ` Andreas Färber
2013-08-09  0:08       ` Rusty Russell
2013-08-09  7:00       ` Rusty Russell
2013-08-09 14:24         ` Andreas Färber
2013-08-09  6:40     ` Rusty Russell
2013-08-09 14:10       ` Anthony Liguori
2013-08-11 23:46         ` Rusty Russell
2013-08-08  5:15 ` [Qemu-devel] [PATCH 2/7] target-ppc: ppc64 targets can be either endian Rusty Russell
2013-08-08  5:15 ` [Qemu-devel] [PATCH 3/7] hw/net/virtio-net: use virtio wrappers to access headers Rusty Russell
2013-08-08 13:32   ` Anthony Liguori
2013-08-08  5:15 ` [Qemu-devel] [PATCH 4/7] hw/net/virtio-balloon: use virtio wrappers to access page frame numbers Rusty Russell
2013-08-08 13:32   ` Anthony Liguori
2013-08-08  5:15 ` [Qemu-devel] [PATCH 5/7] hw/block/virtio-blk: use virtio wrappers to access headers Rusty Russell
2013-08-08  9:57   ` Peter Maydell
2013-08-08 13:32   ` Anthony Liguori
2013-08-08  5:15 ` [Qemu-devel] [PATCH 6/7] hw/scsi/virtio-scsi: " Rusty Russell
2013-08-08 13:33   ` Anthony Liguori
2013-08-08  5:15 ` [Qemu-devel] [PATCH 7/7] hw/char/virtio-serial-bus: " Rusty Russell
2013-08-08 13:34   ` Anthony Liguori
2013-08-08  5:15 ` [Qemu-devel] [PATCH 7/7] patch virtio-serial-biendian.patch Rusty Russell

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=8738qjlzkd.fsf@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=afaerber@suse.de \
    --cc=anton@samba.org \
    --cc=berrange@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    /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).