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

[Marc Zyngier <marc.zyngier@arm.com>]

On Wed, May 07 2014 at 11:40:54 am BST, Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> On Wed, 07 May 2014 10:52:01 +0100
> Marc Zyngier <marc.zyngier@arm.com> wrote:
>
>> On Wed, May 07 2014 at 10:34:30 am BST, Peter Maydell
>> <peter.maydell@linaro.org> wrote:
>> > 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.
>> 
>> 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.

Hi Gregory,

> All the fuzz is not really about enforcing kernel access... PPC also
> has a current endianness selector (MSR_LE) but it only makes sense
> if you are in the cpu context. Initial versions of the virtio biendian
> support for QEMU PPC64 used an arbitrary cpu: in this case, the
> only sensible thing to look at to support kernel based virtio is the 
> interrupt endianness selector (LPCR_ILE), because if gives a safe
> hint of the kernel endianness.
>
> The patch set has evolved and now uses current_cpu at device reset time.
> As a consequence, we are not necessarily tied to the kernel LPCR_ILE
> selector I guess.

That makes a lot of sense, thanks for explaining that. You're basically
doing the exact same thing we do with kvmtool on ARM. So if we have
similar architectural features on both sides, why don't we support both
kernel and userspace access?

Cheers,

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