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

[Alexander Graf <agraf@suse.de>]

On 05/07/2014 12:46 PM, Marc Zyngier wrote:
> On Wed, May 07 2014 at 11:10:56 am BST, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 7 May 2014 10:52, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell
>>> <peter.maydell@linaro.org> wrote:
>>>> 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.
>>> On AArch32, we only have the CPSR.E bit to select the endiannes. Are we
>>> going to simply explode if the access comes from userspace?
>> There's SCTLR.EE in AArch32, right?
> Indeed, good point.
>
>>> On AArch64, we can either select the kernel endianness, or userspace
>>> endianness. Are we going to go a different route just for the sake of
>>> enforcing kernel access?
>>>
>>> I'm inclined to think of userspace access as a valid use case.
>> I don't actually care much about the details of what we decide; I just
>> want us to be consistent between QEMU and kvmtool and (to the extent
>> that architectural differences permit) consistent between PPC and
>> ARM. At the moment we seem to be heading in gratuitously different
>> directions.
> My point is: is there any good technical reason for deciding not to
> support guest user space access, other than religious matters about the
> latest incarnation of The Holy Virtio Spec?

Yes, because it can't be isolated as per the current spec. User space 
has no business in physical addresses. And since so far I haven't heard 
of a single case where people on ARM are either

   a) nesting virtualization or
   b) running different endian user space

I don't think this point is valid. Virtio 1.0 is defined to be little 
endian only, so we don't need all that messy magic logic anymore. By the 
time people will do nesting or different endian user space we will most 
likely be in virtio 1.0 land. Shoehorning in anything in between is just 
a waste of time.

If you like to see a constructed case where your logic falls apart, I 
can easily give you one too (because the whole thing is just insanely 
fragile). Imagine you have nesting. Your L1 guest passes its virtio 
device into the L2 guest with idmap. The L1 guest wants to trace MMIO 
accesses, so it traps on every access and delivers it on its own. L2 is 
LE, L1 is BE. Virtio gets initialized BE even through the guest that 
really wants to access it is LE.


Alex