Re: [Qemu-devel] [PATCH v8 00/20] virtio endian-ambivalent target

[Alexander Graf <agraf@suse.de>]

On 18.06.14 17:35, Peter Maydell wrote:
> On 18 June 2014 15:28, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
>> On Wed, 18 Jun 2014 16:42:04 +0300
>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>> On Wed, Jun 18, 2014 at 01:53:15PM +0100, Peter Maydell wrote:
>>>> On 18 June 2014 11:38, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>>>> What bothers me is that real hardware can't do this.
>>>> Real hardware doesn't have "endianness matches guest CPU endianness"
>>>> semantics, which is what the virtio spec mandates...
>>> So it was buggy. We never thought anyone would do a cross endian CPU :(.
>>> We are fixing it in 1.0.
>>>
>> virtio isn't the only victim... we also have vga. The problem can pop up
>> anywhere you rely on TARGET_WORDS_BIGENDIAN.
> No, relying on TARGET_WORDS_BIGENDIAN is fine. It's only
> a problem if your guest somehow assumes that messing with
> the CPU state changes the behaviour of devices as a random
> side effect. That's true for virtio. I'm pushing that it should not
> be true for VGA (ie that the guest should have to explicitly tell
> the VGA device "be the other endian now"). It's also not true for
> most average devices whose endianness is
> TARGET_WORDS_BIGENDIAN -- it just means they don't
> change behaviour, and if the guest wants to be BE on a
> fundamentally LE hardware device it gets to do the byte
> swapping...

I actually agree with Greg here. We implicitly create different VGA 
adapters today depending on TARGET_WORDS_BIGENDIAN. The FB endianness 
should have been separate devices (BE / LE) or runtime configuration 
from the beginning.

Anything that checks TARGET_WORDS_BIGENDIAN in hw/ is very likely to do 
something pretty wrong ;).


Alex