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

From: [email-masked] (Marc Zyngier)
Date: Mon, 14 Oct 2013 15:13:13 +0100

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 <[email-masked]> wrote:
>>>
>>>> On 14/10/13 14:10, Alexander Graf wrote:
>>>>>
>>>>> On 14.10.2013, at 15:03, Paolo Bonzini <[email-masked]> 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?

	M.
-- 
Jazz is not dead. It just smells funny...