On Wed, 7 May 2014 13:17:51 +0100
Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> On 7 May 2014 12:04, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
> > On Wed, May 07 2014 at 11:40:54 am BST, Greg Kurz <gkurz@xxxxxxxxxxxxxxxxxx> wrote:
> >> 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.
>
> Ah yes, I'd forgotten the history behind why we ended up looking
> at interrupt endianness.
>
> > 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?
>
> I don't think that we really need to get into whether userspace
> access is or is not a good idea -- "endianness of the CPU which
> does the virtio reset at the point when it does that reset" is a
> nice simple rule that should generalise across architectures,
> so why make it more complicated than that?
>
> thanks
> -- PMM
>
I am convinced... and feeling a bit guilty for all the noise ;)
I'll come with a new virtio patch set for QEMU that does just what
you say.
--
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
