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

[Marc Zyngier <marc.zyngier@arm.com>]

On 07/05/14 12:49, Alexander Graf wrote:
> 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 

Alex, please read my lips: at the moment, I don't care about virtio-1.0.
At all. Doesn't register. And hammering it on and on won't change a
thing (yes, I've rewritten this sentence at least five times to remove
all the fscking swear words).

> 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 don't want to support it on your pet platform/environment, fine.

> 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.

Then it is a bug in your L1 that doesn't properly emulate accesses it
traps. Not that I care, really.

That being said, I'm going to stop replying to this thread, and instead
go back writing code, posting it, and getting on with my life in
virtio-legacy land.

Thanks,

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