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