On 07/05/14 12:49, Alexander Graf wrote: > On 05/07/2014 12:46 PM, Marc Zyngier wrote: >> On Wed, May 07 2014 at 11:10:56 am BST, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >>> On 7 May 2014 10:52, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell >>>> <peter.maydell@xxxxxxxxxx> wrote: >>>>> 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? >>> There's SCTLR.EE in AArch32, right? >> Indeed, good point. >> >>>> 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. >>> I don't actually care much about the details of what we decide; I just >>> want us to be consistent between QEMU and kvmtool and (to the extent >>> that architectural differences permit) consistent between PPC and >>> ARM. At the moment we seem to be heading in gratuitously different >>> directions. >> My point is: is there any good technical reason for deciding not to >> support guest user space access, other than religious matters about the >> latest incarnation of The Holy Virtio Spec? > > Yes, because it can't be isolated as per the current spec. User space > has no business in physical addresses. And since so far I haven't heard > of a single case where people on ARM are either > > a) nesting virtualization or > b) running different endian user space > > I don't think this point is valid. Virtio 1.0 is defined to be little > endian only, so we don't need all that messy magic logic anymore. By the Alex, please read my lips: at the moment, I don't care about virtio-1.0. At all. Doesn't register. And hammering it on and on won't change a thing (yes, I've rewritten this sentence at least five times to remove all the fscking swear words). > time people will do nesting or different endian user space we will most > likely be in virtio 1.0 land. Shoehorning in anything in between is just > a waste of time. If you don't want to support it on your pet platform/environment, fine. > If you like to see a constructed case where your logic falls apart, I > can easily give you one too (because the whole thing is just insanely > fragile). Imagine you have nesting. Your L1 guest passes its virtio > device into the L2 guest with idmap. The L1 guest wants to trace MMIO > accesses, so it traps on every access and delivers it on its own. L2 is > LE, L1 is BE. Virtio gets initialized BE even through the guest that > really wants to access it is LE. Then it is a bug in your L1 that doesn't properly emulate accesses it traps. Not that I care, really. That being said, I'm going to stop replying to this thread, and instead go back writing code, posting it, and getting on with my life in virtio-legacy land. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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
