Re: [kvm-devel] [kvm-ppc-devel] RFC: MMIO endianness flag

[Xu, A. <ant...@in...>]

> Here is the concrete example:
>       * guest writes to MMIO
>       * KVM passes MMIO information (physical address, number of
>         bytes, value) to qemu
		The value is saved in memory, is it bigendian or
littleendian?

>       * Qemu knows from the address that this access is for a
>         passthough device, a special case the administrator has
>       pre-configured * Qemu does mmap(/dev/mem), and writes "length"

		When qemu writes value, Can qemu know what
mode(bigendian/littleendian it is running)?
	Qemu can run on bigendian in IA64.

>         bytes of "value" at offset "address".
>=20

Hollis Blanchard wrote:
> On Sun, 2008-01-13 at 11:42 +0200, Avi Kivity wrote:
>=20
>> 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.=20
>>=20
>> Or maybe even the kernel can do this by itself?
>=20
> The kernel *already* does this by itself, and I'm attempting to
> explain why that is not sufficient.
>=20
> My point is precisely that the endianness information must be
> propagated to the user, otherwise the user may not have all the
> information it needs to emulate it.
>=20
> Here is the concrete example:
>       * guest writes to MMIO
>       * KVM passes MMIO information (physical address, number of
>         bytes, value) to qemu
>       * Qemu knows from the address that this access is for a
>         passthough device, a special case the administrator has
>       pre-configured * Qemu does mmap(/dev/mem), and writes "length"
>         bytes of "value" at offset "address".
>=20
> Now here's the catch: what endianness does qemu use when doing the
> write? If qemu only does BE, then a LE access from the guest will be
> byte-reversed when presented to the real hardware.