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