From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness Date: Thu, 08 May 2014 11:22:53 +0930 Message-ID: <87eh05niiy.fsf@rustcorp.com.au> 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> <536A06C1.8010709@suse.de> 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 , Michael Tsirkin To: Alexander Graf , Marc Zyngier Return-path: Received: from ozlabs.org ([103.22.144.67]:59376 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751250AbaEICeR (ORCPT ); Thu, 8 May 2014 22:34:17 -0400 In-Reply-To: <536A06C1.8010709@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf writes: > On 05/07/2014 11:57 AM, Marc Zyngier wrote: >>>>> 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. Slightly orthogonal: virtio 1.0 is LE, so endianness is solved. > Of course alternatively we can continue bikeshedding about this until > everything becomes moot because we switched to virtio 1.0 ;). Transition will be long... > Rusty / Michael, virtio 1.0 does go via normal DMA channels, right? No. We argued about this; it's more PCI-like to do, but there's a performance cost and it's really unclear that passing through a virtio PCI device to a (sub)guest is a scenario worth supporting. Maybe someone will come up with a convincing reason, and we'll add a feature bit in a future revision... Cheers, Rusty.