From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kurz Subject: Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness Date: Wed, 7 May 2014 12:40:54 +0200 Message-ID: <20140507124054.680a26fb@bahia.local> 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; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Will Deacon , Pekka Enberg , "kvmarm\@lists.cs.columbia.edu" , "kvm\@vger.kernel.org" , "agraf\@suse.de" To: Marc Zyngier Return-path: Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:34653 "EHLO e06smtp11.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932157AbaEGKlF (ORCPT ); Wed, 7 May 2014 06:41:05 -0400 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 May 2014 11:41:03 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2BEE31B08040 for ; Wed, 7 May 2014 11:41:11 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s47Aex3n4588004 for ; Wed, 7 May 2014 10:40:59 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s47AewDO002110 for ; Wed, 7 May 2014 04:40:59 -0600 In-Reply-To: <8738glq5ku.fsf@approximate.cambridge.arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 07 May 2014 10:52:01 +0100 Marc Zyngier wrote: > 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. > > M. All the fuzz is not really about enforcing kernel access... PPC also has a current endianness selector (MSR_LE) but it only makes sense if you are in the cpu context. Initial versions of the virtio biendian support for QEMU PPC64 used an arbitrary cpu: in this case, the only sensible thing to look at to support kernel based virtio is the interrupt endianness selector (LPCR_ILE), because if gives a safe hint of the kernel endianness. The patch set has evolved and now uses current_cpu at device reset time. As a consequence, we are not necessarily tied to the kernel LPCR_ILE selector I guess. Cheers. -- Gregory Kurz kurzgreg@fr.ibm.com gkurz@linux.vnet.ibm.com Software Engineer @ IBM/Meiosys http://www.ibm.com Tel +33 (0)562 165 496 "Anarchy is about taking complete responsibility for yourself." Alan Moore.