qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and c


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1/7] virtio: allow byte swapping for vring and config access
Date: Thu, 08 Aug 2013 11:25:22 -0500
User-agent: Notmuch/0.15.2+202~g0c4b8aa (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Peter Maydell <address@hidden> writes:

> On 8 August 2013 17:07, Anthony Liguori <address@hidden> wrote:
>> It's the same processor.  It still starts executing big endian
>> instructions.  A magic register value is tweaked and loads/stores are
>> swapped.
>
> I dunno about PPC, but for ARM generally the boot-up state is
> controlled by config signals which a SoC or board can hardwire,
> so you can have a SoC which is configured to start in big-endian
> mode.
>
>> CPU data structures are still read as big endian though.
>
> Do you have an example of what you mean by "CPU data structure"?

MMU tlb hash table.  If you grep ldl target-ppc/* you'll see that there
are only a few cases where bswap occurs.

>> The distinction is important in QEMU.  ppc64 is still
>> TARGET_WORDS_BIGENDIAN.
>
> Ideally TARGET_WORDS_BIGENDIAN would go away -- it is forcing
> at compile time a setting which is actually a runtime one,
> and a lot of the weirdness here flows from that.
>
>> We still want most stl_phys to treat integers
>> as big endian.
>
> Any stl_phys() should [in an ideal design] be tied to a
> "bus master" which has its own idea of which endianness
> it is. That is, an stl_phys() for a DMA controller model
> ought to use the endianness programmed for the DMA controller,
> not whatever the CPU happens to be using.

We have the DMA API that attempts to do this but maybe we need to
generalize it a bit more...

I think it's pretty true that we need a context and that the context
for, say instruction fetch, is distinct from the context for load/store
instructions.

Regards,

Anthony Liguori

>
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]