[PATCH 0/3] virtio-mmio: handle BE guests on LE hosts

[Alexander Graf]

On 14.10.2013, at 16:13, Marc Zyngier <marc.zyngier at arm.com> wrote:

> On 14/10/13 15:05, Michael S. Tsirkin wrote:
>> On Mon, Oct 14, 2013 at 02:49:10PM +0100, Marc Zyngier wrote:
>>> On 14/10/13 14:39, Alexander Graf wrote:
>>>> 
>>>> On 14.10.2013, at 15:24, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> 
>>>>> On 14/10/13 14:10, Alexander Graf wrote:
>>>>>> 
>>>>>> On 14.10.2013, at 15:03, Paolo Bonzini <pbonzini at redhat.com> wrote:
>>>>>> 
>>>>>>> Il 11/10/2013 16:36, Marc Zyngier ha scritto:
>>>>>>>> This small patch series adds just enough kernel infrastructure and
>>>>>>>> fixes to allow a BE guest to use virtio-mmio on a LE host, provided
>>>>>>>> that the host actually supports such madness.
>>>>>>> 
>>>>>>> More precisely, it allows the guest drivers to pick the endianness they
>>>>>>> prefer.  Mixed-endian virtio works fine on QEMU with e.g. a mips guest
>>>>>>> in emulation mode, because then any given QEMU binary will always use
>>>>>>> the same endianness (e.g. big for qemu-system-mips).
>>>>>> 
>>>>>> We have the same problem (runtime switchable endianness) on PowerPC. IBM POWER is gaining Little Endian support in Linux now, so we could easily end up with an LE guest on a BE host.
>>>>>> 
>>>>>> IIRC the way we're going to solve this is to hack up virtio_is_big_endian() to evaluate the first CPU's endianness mode (which will always be the same as all other CPU's endianness mode due to hypercall restrictions).
>>>>> 
>>>>> I have implemented something similar for MMIO emulation in KVM/arm
>>>>> (except that I only care about the faulting CPU).
>>>>> 
>>>>> See my initial patch for that:
>>>>> https://lists.cs.columbia.edu/pipermail/kvmarm/2013-October/007359.html
>>>>> 
>>>>> That doesn't really change the non-trapping virtio accesses, though.
>>>>> Where is this virtio_is_big_endian() thing?
>>>> 
>>>> It's in QEMU's exec.c. It only gets used for config space access that goes through PCI though. Is there any other place where virtio specifies native endianness today?
>>> 
>>> That's the main problem. Today's virtio flavour doesn't specify anything
>>> about endianness, and that is what I'm adding. Or rather (as Paolo put
>>> it), the prefered endianness of the virtio driver.
>>> 
>>> So once (and if) this flags are in place, you always know what you're
>>> dealing with. And because it is virtio-centric, you can implement it in
>>> an architecture independent way.
>>> 
>>> Also, most of my life revolves around kvmtool. QEMU is hardly on my
>>> radar, these days (for reasons that are neither technical, nor relevant
>>> to this forum). So it is important to me that the solution is platform
>>> emulation agnostic.
>>> 
>>> 	M.
>> 
>> f you like, you should be able to implement virtio_is_big_endian
>> in kvmtool too.
> 
> Sure. And I imagine this traps back into the kernel to read some
> register and find out what the endianness of the accessing CPU is?

Not yet. To be exact, it does the below today. But all virtio device emulation is 100% guest endianness unaware. This helper is the only piece of code where it gets any idea what endianness the guest has. So by checking for references to it in the code you know where endianness is an issue. And that's only in the config space.


Alex


bool virtio_is_big_endian(void)
{
#if defined(TARGET_WORDS_BIGENDIAN)
    return true;
#else
    return false;
#endif
}