From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: RFC: MMIO endianness flag Date: Thu, 10 Jan 2008 08:56:25 +0200 Message-ID: <4785C199.9040002@qumranet.com> References: <1199920008.5637.48.camel@basalt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel , kvm-devel To: Hollis Blanchard Return-path: In-Reply-To: <1199920008.5637.48.camel@basalt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.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 > --- > > 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