Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access

[Peter Maydell]

On 9 August 2013 03:58, Rusty Russell <address@hidden> wrote:
> Anthony Liguori <address@hidden> 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.

Agreed (subject to the complicating factor that it's possible for
a CPU to have the order to be different for data, instruction and
TLB walk loads, so it's not a single setting for a CPU).

> From any reasonable definition, PPC is bi-endian.
>
> It's actually a weird thing for the qemu core to know at all:

It's a TCG performance optimisation and/or simplification hack,
basically -- by hardcoding the endianness we think the core is at
compile time we can either always-byteswap or never-byteswap in the
fast paths.

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

The code for actually doing TCG CPU loads and stores cares too.

notdirty_mem_write is (I think) part of how we handle self-modifying
code: if you write to a page in memory that we have translated some
code from, then we need to intercept that write so that we can throw
away the translated code. notdirty_mem_write() is the function that
does that interception, throws away the code, figures out if we still
need to intercept next time around, and actually does the access
the guest asked for. (It might also be used for spotting when the
guest touches memory during migration and thus that page needs to be
retransmitted -- I haven't checked.)

-- PMM