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.
Hi Marc :-)
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...
thanks
-- PMM
--
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
