From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness Date: Wed, 07 May 2014 13:49:33 +0200 Message-ID: <536A1DCD.8000901@suse.de> 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> <8738glq5ku.fsf@approximate.cambridge.arm.com> <87lhudoogt.fsf@approximate.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Will Deacon , Pekka Enberg , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , Greg Kurz To: Marc Zyngier Return-path: Received: from cantor2.suse.de ([195.135.220.15]:59368 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755692AbaEGLtf (ORCPT ); Wed, 7 May 2014 07:49:35 -0400 In-Reply-To: <87lhudoogt.fsf@approximate.cambridge.arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/07/2014 12:46 PM, Marc Zyngier wrote: > On Wed, May 07 2014 at 11:10:56 am BST, Peter Maydell wrote: >> On 7 May 2014 10:52, Marc Zyngier wrote: >>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell >>> 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