Alexander Graf <agraf@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
