Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness

From: Marc Zyngier <marc.zyngier@arm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Pekka Enberg <penberg@kernel.org>,
	"kvmarm\@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"kvm\@vger.kernel.org" <kvm@vger.kernel.org>,
	Greg Kurz <gkurz@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 9/9] kvmtool: virtio: enable arm/arm64 support for bi-endianness
Date: Wed, 07 May 2014 10:57:01 +0100	[thread overview]
Message-ID: <87y4ydoqs2.fsf@approximate.cambridge.arm.com> (raw)
In-Reply-To: <CEC61FE8-AAF2-4EAA-B9E4-43A5D8640000@suse.de> (Alexander Graf's message of "Wed, 7 May 2014 10:42:54 +0100")

On Wed, May 07 2014 at 10:42:54 am BST, Alexander Graf <agraf@suse.de> wrote:
>> Am 07.05.2014 um 11:34 schrieb Peter Maydell <peter.maydell@linaro.org>:
>> 
>>> On 6 May 2014 19:38, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> On 6 May 2014 18:25, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>>>> On Tue, May 06 2014 at  3:28:07 pm BST, Will Deacon <will.deacon@arm.com> 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, &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.
>
> Virtio by design has full access to guest physical memory. It doesn't
> route DMA via PCI. So user space drivers simply don't make sense here.

Huh? What if my guest has usespace using an idmap, with Stage-1 MMU for
isolation only (much like an MPU)? R-class guests anyone?

Agreed, this is not the general use case, but that doesn't seem to be
completely unrealistic either.

	M.
-- 
Jazz is not dead. It just smells funny.