On 14/10/13 14:39, Alexander Graf wrote:
>
> On 14.10.2013, at 15:24, Marc Zyngier <[email protected]> wrote:
>
>> On 14/10/13 14:10, Alexander Graf wrote:
>>>
>>> On 14.10.2013, at 15:03, Paolo Bonzini <[email protected]> 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.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
