On Wed, May 07, 2014 at 12:11:13PM +0200, Alexander Graf wrote:
> 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
By default it doesn't at the moment, in particular IOMMUs really
seem to hurt performance when enabled, and many guests seem to be
dumb and enable it everywhere if present.
By design IOMMUs can protect you from malicious devices, which
is relevant if you assign a device but of course isn't
relevant for qemu as virtio is part of qemu atm.
In virtio 1.0 it's possible for a device to have "required features"
which drivers must ack.
So we'll be able to have hypervisor tell guest that it requires DMA for
some VFs.
You would then be able to do mix fast virtio PF bypassing IOMMU and handle
that in kernel, and slow virtio VF going through an IOMMU and handle that
in userspace.
--
MST
--
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
