On 05/07/2014 11:57 AM, Marc Zyngier wrote:
On Wed, May 07 2014 at 10:42:54 am BST, Alexander Graf <agraf@xxxxxxx> wrote:
Am 07.05.2014 um 11:34 schrieb Peter Maydell <peter.maydell@xxxxxxxxxx>:
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.
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.
Yes, and once that user tries the same without idmap virtio ends up
overwriting random memory. It's just not a good idea and I'd much rather
see us solve this properly with virtio 1.0 really.
Of course alternatively we can continue bikeshedding about this until
everything becomes moot because we switched to virtio 1.0 ;).
Rusty / Michael, virtio 1.0 does go via normal DMA channels, right?
Alex
--
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
