From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness Date: Wed, 07 May 2014 13:16:13 +0100 Message-ID: <536A240D.8060000@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> <8738glq5ku.fsf@approximate.cambridge.arm.com> <87lhudoogt.fsf@approximate.cambridge.arm.com> <536A1DCD.8000901@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Will Deacon , Pekka Enberg , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , Greg Kurz To: Alexander Graf Return-path: Received: from fw-tnat.austin.arm.com ([217.140.110.23]:29902 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751190AbaEGMQQ (ORCPT ); Wed, 7 May 2014 08:16:16 -0400 In-Reply-To: <536A1DCD.8000901@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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 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 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...