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
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 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.
Alex
--
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
