On Mon, 24 Feb 2020 17:26:20 +0800 Jason Wang <jasowang@xxxxxxxxxx> wrote: > That's better. > > How about attached? > > Thanks Thanks Jason! It does avoid the translation overhead in vhost. Tested-by: Halil Pasic <pasic@xxxxxxxxxxxxx> Regarding the code, you fence it in virtio-net.c, but AFAIU this feature has relevance for other vhost devices as well. E.g. what about vhost user? Would it be the responsibility of each virtio device to fence this on its own? I'm also a bit confused about the semantics of the vhost feature bit F_ACCESS_PLATFORM. What we have specified on virtio level is: """ This feature indicates that the device can be used on a platform where device access to data in memory is limited and/or translated. E.g. this is the case if the device can be located behind an IOMMU that translates bus addresses from the device into physical addresses in memory, if the device can be limited to only access certain memory addresses or if special commands such as a cache flush can be needed to synchronise data in memory with the device. Whether accesses are actually limited or translated is described by platform-specific means. If this feature bit is set to 0, then the device has same access to memory addresses supplied to it as the driver has. In particular, 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, and can access any address supplied to it by the driver. When clear, this overrides any platform-specific description of whether device access is limited or translated in any way, e.g. whether an IOMMU may be present. """ I read this like the addresses may be IOVAs which require IMMU translation or GPAs which don't. On the vhost level however, it seems that F_IOMMU_PLATFORM means that vhost has to do the translation (via IOTLB API). Do I understand this correctly? If yes, I believe we should document this properly. BTW I'm still not 100% on the purpose and semantics of the F_ACCESS_PLATFORM feature bit. But that is a different problem. Regards, Halil _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
