On Wed, May 07 2014 at 10:55:45 am BST, Alexander Graf <agraf@xxxxxxx> wrote:
>> Am 07.05.2014 um 11:52 schrieb Marc Zyngier <marc.zyngier@xxxxxxx>:
>>
>>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell
>>> <peter.maydell@xxxxxxxxxx> wrote:
>>>> On 6 May 2014 19:38, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
>>>>> On 6 May 2014 18:25, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>>>>>> On Tue, May 06 2014 at 3:28:07 pm BST, Will Deacon
>>>>>> <will.deacon@xxxxxxx> wrote:
>>>>>>> On Thu, Apr 24, 2014 at 07:17:23PM +0100, Marc Zyngier wrote:
>>>>>>> + reg.addr = (u64)&data;
>>>>>>> + if (ioctl(vcpu->vcpu_fd, KVM_GET_ONE_REG, ®) < 0)
>>>>>>> + die("KVM_GET_ONE_REG failed (SCTLR_EL1)");
>>>>>>> +
>>>>>>> + return (data & SCTLR_EL1_EE_MASK) ? VIRTIO_ENDIAN_BE :
>>>>>>> VIRTIO_ENDIAN_LE;
>>>>>>
>>>>>> This rules out guests where userspace and kernelspace can run
>>>>>> with different
>>>>>> endinness. Whilst Linux doesn't currently do this, can we support it here?
>>>>>> It all gets a bit hairy if the guest is using a stage-1 SMMU to let
>>>>>> userspace play with a virtio device...
>>>>>
>>>>> Yeah, I suppose we could check either EE or E0 depending on the mode
>>>>> when the access was made. We already have all the information, just need
>>>>> to handle the case. I'll respin the series.
>>>
>>>> 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.
>>
>> 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?
>>
>> 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.
>
> It's not for virtio-legacy. It'll be much more productive to influence
> virtio-1.0 to not redo the same mistakes than enabling even more
> hackery with the legacy one.
Are you saying I shouldn't improve an existing code base and implement a
useful feature, and should instead work on some new fancy stuff for
which there is no platform support, no kernel support, and not an
official spec either? Watch me.
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
