Re: RFC: MMIO endianness flag

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Hollis Blanchard wrote:
> Add an "is_bigendian" flag to the kvm_run.mmio structure.
>
> This is needed for architectures that can make both little- and
> big-endian memory accesses.
>
> Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
>
> PowerPC has different instructions for native and byte-reversed memory
> accesses, and some implementations can also can map individual pages as
> byte-reversed. Right now in the PowerPC KVM implementation the kernel
> detects byte-reversed MMIO from the guest and converts the data as
> appropriate so that userland only ever deals with big-endian data.
>
> That's fine and all, but I started thinking about supporting MMIO
> passthrough, in which userland wouldn't emulate an MMIO at all, but
> rather execute it on the real hardware (via mmap /dev/mem, for example).
>
> In that case, it's actually very important that the endianness of the
> access be preserved, since we need that information to access the real
> hardware.
>
> I don't think this patch has any serious x86 ABI implications, since
> current x86 code just ignores the flag. I guess x86 could continue to
> ignore it in the future, or it could explicitly zero the new flag.
>   

Ignoring the field is better since older kernels won't zero it.

IIRC endianness is a per-page attribute on ppc, no?  Otherwise you'd 
have a global attribute instead of per-access.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace