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

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

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?

Thanks,

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