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 11:19:04 +0100 Message-ID: <87tx91oprb.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> <8738glq5ku.fsf@approximate.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain 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]:34380 "EHLO collaborate-mta1.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932410AbaEGKTH (ORCPT ); Wed, 7 May 2014 06:19:07 -0400 In-Reply-To: (Alexander Graf's message of "Wed, 7 May 2014 10:55:45 +0100") Sender: kvm-owner@vger.kernel.org List-ID: On Wed, May 07 2014 at 10:55:45 am BST, Alexander Graf wrote: >> Am 07.05.2014 um 11:52 schrieb Marc Zyngier : >> >>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell >>> wrote: >>>> On 6 May 2014 19:38, Peter Maydell wrote: >>>>> On 6 May 2014 18:25, Marc Zyngier wrote: >>>>>> On Tue, May 06 2014 at 3:28:07 pm BST, Will Deacon >>>>>> wrote: >>>>>>> On Thu, Apr 24, 2014 at 07:17:23PM +0100, Marc Zyngier wrote: >>>>>>> + reg.addr = (u64)&data; >>>>>>> + if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, ®) < 0) >>>>>>> + die("KVM_GET_ONE_REG failed (SCTLR_EL1)"); >>>>>>> + >>>>>>> + return (data & SCTLR_EL1_EE_MASK) ? VIRTIO_ENDIAN_BE : >>>>>>> VIRTIO_ENDIAN_LE; >>>>>> >>>>>> This rules out guests where userspace and kernelspace can run >>>>>> with different >>>>>> endinness. Whilst Linux doesn't currently do this, can we support it here? >>>>>> It all gets a bit hairy if the guest is using a stage-1 SMMU to let >>>>>> userspace play with a virtio device... >>>>> >>>>> Yeah, I suppose we could check either EE or E0 depending on the mode >>>>> when the access was made. We already have all the information, just need >>>>> to handle the case. I'll respin the series. >>> >>>> How virtio implementations should determine their endianness is >>>> a spec question, I think; at any rate QEMU and kvmtool ought to >>>> agree on how it's done. I think the most recent suggestion on the >>>> QEMU mailing list (for PPC) is that we should care about the >>>> guest kernel endianness, but I don't know if anybody thought of >>>> the pass-through-to-userspace usecase... >>> >>> 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? >> >> 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. > > It's not for virtio-legacy. It'll be much more productive to influence > virtio-1.0 to not redo the same mistakes than enabling even more > hackery with the legacy one. Are you saying I shouldn't improve an existing code base and implement a useful feature, and should instead work on some new fancy stuff for which there is no platform support, no kernel support, and not an official spec either? Watch me. M. -- Jazz is not dead. It just smells funny.