On 9 August 2013 03:58, Rusty Russell <ru...@rustcorp.com.au> wrote: > Anthony Liguori <anth...@codemonkey.ws> 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
