Hollis Blanchard wrote:
> On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
>
>> I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't
>> use it by mistake).
>>
>
> I don't think that's the right ifdef. For example, I believe IA64 can
> run in BE mode and so will have the same issue, and there are certainly
> other architectures (less relevant to the current code) that definitely
> are in the same situation.
>
> We need to plumb this through to the libkvm users anyways. Take a look
> at the patch below and tell me if you think it's not the right approach.
> x86 simply won't consider 'is_bigendian'. I spent a lot of time on this,
> and it's by far the cleanest solution I could come up with.
>
>
>
>
> +#ifdef ARCH_MMIO_ENDIAN_BIG
> +static int handle_mmio_bigendian(kvm_context_t kvm, struct kvm_run *kvm_run)
> +{
> + if (kvm_run->mmio.is_write)
> + return kvm->callbacks->mmio_write_be(kvm->opaque,
> + kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> + else
> + return kvm->callbacks->mmio_read_be(kvm->opaque,
> + kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> +}
> +#endif
>
Do we really need to propagate endianness all the way to the user?
Perhaps libkvm could call the regular mmio functions and do the
transformation itself.
Or maybe even the kernel can do this by itself?
--
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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
