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, 7 May 2014 11:42:54 +0200 Message-ID: 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> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Cc: Marc Zyngier , Will Deacon , Pekka Enberg , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , Greg Kurz To: Peter Maydell Return-path: Received: from cantor2.suse.de ([195.135.220.15]:56961 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751886AbaEGJm5 convert rfc822-to-8bit (ORCPT ); Wed, 7 May 2014 05:42:57 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: > Am 07.05.2014 um 11:34 schrieb Peter Maydell : > >> 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. Virtio by design has full access to guest physical memory. It doesn't route DMA via PCI. So user space drivers simply don't make sense here. Alex