Michael S. Tsirkin <mst@xxxxxxxxxx> writes: > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst@xxxxxxxxxx> writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> I rephrased it in terms of address translation. What do you think of >> >> this version? The flag name is slightly different too: >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> >> with the exception that address translation is guaranteed to be >> >> unnecessary when accessing memory addresses supplied to the device >> >> by the driver. Which is to say, the device will always use physical >> >> addresses matching addresses used by the driver (typically meaning >> >> physical addresses used by the CPU) and not translated further. This >> >> flag should be set by the guest if offered, but to allow for >> >> backward-compatibility device implementations allow for it to be >> >> left unset by the guest. It is an error to set both this flag and >> >> VIRTIO_F_ACCESS_PLATFORM. >> > >> > >> > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged >> > drivers. This is why devices fail when it's not negotiated. >> >> Just to clarify, what do you mean by unprivileged drivers? Is it drivers >> implemented in guest userspace such as with VFIO? Or unprivileged in >> some other sense such as needing to use bounce buffers for some reason? > > I had drivers in guest userspace in mind. Great. Thanks for clarifying. I don't think this flag would work for guest userspace drivers. Should I add a note about that in the flag definition? >> > This confuses me. >> > If driver is unpriveledged then what happens with this flag? >> > It can supply any address it wants. Will that corrupt kernel >> > memory? >> >> Not needing address translation doesn't necessarily mean that there's no >> IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's >> always an IOMMU present. And we also support VFIO drivers. The VFIO API >> for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls >> to program the IOMMU. >> >> For our use case, we don't need address translation because we set up an >> identity mapping in the IOMMU so that the device can use guest physical >> addresses. > > And can it access any guest physical address? Sorry, I was mistaken. We do support VFIO in guests but not for virtio devices, only for regular PCI devices. In which case they will use address translation. >> If the guest kernel is concerned that an unprivileged driver could >> jeopardize its integrity it should not negotiate this feature flag. > > Unfortunately flag negotiation is done through config space > and so can be overwritten by the driver. Ok, so the guest kernel has to forbid VFIO access on devices where this flag is advertised. >> Perhaps there should be a note about this in the flag definition? This >> concern is platform-dependant though. I don't believe it's an issue in >> pseries. > > Again ACCESS_PLATFORM has a pretty open definition. It does actually > say it's all up to the platform. > > Specifically how will VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION be > implemented portably? virtio has no portable way to know > whether DMA API bypasses translation. The fact that VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION is set communicates that knowledge to virtio. There is a shared understanding between the guest and the host about what this flag being set means. -- Thiago Jung Bauermann IBM Linux Technology Center _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
