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