From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness
Date: Wed, 07 May 2014 11:46:58 +0100
Message-ID: <87lhudoogt.fsf@approximate.cambridge.arm.com>
References: <1398363443-3764-1-git-send-email-marc.zyngier@arm.com>
	<1398363443-3764-10-git-send-email-marc.zyngier@arm.com>
	<20140506142807.GI30234@arm.com>
	<87mweuq0os.fsf@approximate.cambridge.arm.com>
	<CAFEAcA-NhyvE5KEGcer0zGW-rmfJgr9PaWUB+rYk+H0rw0BGbA@mail.gmail.com>
	<CAFEAcA8AeCVGPu0d1=F2YODDSqn6RiCYXWjEWkiiaVSZyQbSUA@mail.gmail.com>
	<8738glq5ku.fsf@approximate.cambridge.arm.com>
	<CAFEAcA-TP0D7X0MXTWhgn2pu_gmwakSoNUSe4t6ZpayCrr4png@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Cc: Will Deacon <Will.Deacon@arm.com>,
	Pekka Enberg <penberg@kernel.org>,
	"kvmarm\@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"kvm\@vger.kernel.org" <kvm@vger.kernel.org>,
	"agraf\@suse.de" <agraf@suse.de>,
	Greg Kurz <gkurz@linux.vnet.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from fw-tnat.austin.arm.com ([217.140.110.23]:43283 "EHLO
	collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S932181AbaEGKrA (ORCPT
	<rfc822;kvm@vger.kernel.org>); Wed, 7 May 2014 06:47:00 -0400
In-Reply-To: <CAFEAcA-TP0D7X0MXTWhgn2pu_gmwakSoNUSe4t6ZpayCrr4png@mail.gmail.com>
	(Peter Maydell's message of "Wed, 7 May 2014 11:10:56 +0100")
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.