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 12:11:13 +0200 Message-ID: <536A06C1.8010709@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> <87y4ydoqs2.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 , Rusty Russell , Michael Tsirkin To: Marc Zyngier Return-path: Received: from cantor2.suse.de ([195.135.220.15]:57515 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754472AbaEGKLQ (ORCPT ); Wed, 7 May 2014 06:11:16 -0400 In-Reply-To: <87y4ydoqs2.fsf@approximate.cambridge.arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/07/2014 11:57 AM, Marc Zyngier wrote: > On Wed, May 07 2014 at 10:42:54 am BST, Alexander Graf wrote: >>> 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. > Huh? What if my guest has usespace using an idmap, with Stage-1 MMU for > isolation only (much like an MPU)? R-class guests anyone? > > Agreed, this is not the general use case, but that doesn't seem to be > completely unrealistic either. Yes, and once that user tries the same without idmap virtio ends up overwriting random memory. It's just not a good idea and I'd much rather see us solve this properly with virtio 1.0 really. Of course alternatively we can continue bikeshedding about this until everything becomes moot because we switched to virtio 1.0 ;). Rusty / Michael, virtio 1.0 does go via normal DMA channels, right? Alex