On Wed, 07 May 2014 10:52:01 +0100
Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
> 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.
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.
Cheers.
--
Gregory Kurz kurzgreg@xxxxxxxxxx
gkurz@xxxxxxxxxxxxxxxxxx
Software Engineer @ IBM/Meiosys http://www.ibm.com
Tel +33 (0)562 165 496
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
--
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
