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
>> <[email protected]> wrote:
>>> On 7 May 2014 10:52, Marc Zyngier <[email protected]> wrote:
>>>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell
>>>> <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
