Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness

[Rusty Russell <rusty@rustcorp.com.au>]

Alexander Graf <agraf@suse.de> writes:
> On 05/07/2014 11:57 AM, Marc Zyngier wrote:
>>>>> How virtio implementations should determine their endianness is
>>>>> a spec question, I think; at any rate QEMU and kvmtool ought to
>>>>> agree on how it's done. I think the most recent suggestion on the
>>>>> QEMU mailing list (for PPC) is that we should care about the
>>>>> guest kernel endianness, but I don't know if anybody thought of
>>>>> the pass-through-to-userspace usecase...
>>>> Current opinion on the qemu-devel thread seems to be that we
>>>> should just define that the endianness of the virtio device is
>>>> the endianness of the guest kernel at the point where the guest
>>>> triggers a reset of the virtio device by writing zero the QueuePFN
>>>> or Status registers.
>>> Virtio by design has full access to guest physical memory. It doesn't
>>> route DMA via PCI. So user space drivers simply don't make sense here.
>> Huh? What if my guest has usespace using an idmap, with Stage-1 MMU for
>> isolation only (much like an MPU)? R-class guests anyone?
>>
>> Agreed, this is not the general use case, but that doesn't seem to be
>> completely unrealistic either.
>
> Yes, and once that user tries the same without idmap virtio ends up 
> overwriting random memory. It's just not a good idea and I'd much rather 
> see us solve this properly with virtio 1.0 really.

Slightly orthogonal: virtio 1.0 is LE, so endianness is solved.

> Of course alternatively we can continue bikeshedding about this until 
> everything becomes moot because we switched to virtio 1.0 ;).

Transition will be long...

> Rusty / Michael, virtio 1.0 does go via normal DMA channels, right?

No.  We argued about this; it's more PCI-like to do, but there's a
performance cost and it's really unclear that passing through a virtio
PCI device to a (sub)guest is a scenario worth supporting.

Maybe someone will come up with a convincing reason, and we'll add
a feature bit in a future revision...

Cheers,
Rusty.