On Wed, Oct 28, 2020 at 03:24:03PM +0100, Alexander Graf wrote: > On 24.02.20 18:16, Christoph Hellwig wrote: > > On Sat, Feb 22, 2020 at 02:07:58PM -0500, Michael S. Tsirkin wrote: > > > On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote: > > > > AFAIU you have a positive attitude towards the idea, that > > > > !F_VIRTIO_PLATFORM implies 'no DMA API is used by virtio' > > > > should be scrapped. > > > > > > > > I would like to accomplish that without adverse effects to virtio-ccw > > > > (because caring for virtio-ccw is a part of job description). > > > > > > > > Regards, > > > > Halil > > > > > > It is possible, in theory. IIRC the main challenge is that DMA API > > > has overhead of indirect function calls even when all it > > > does it return back the PA without changes. > > > > That overhead is gone now, the DMA direct calls are direct calls these > > days. > > Michael, would that mitigate your concerns to just always use the DMA API? > If not, wouldn't it make sense to benchmark and pinpoint Christoph to paths > that do slow things down, so we can finally move virtio into a world where > it doesn't bypass the kernel DMA infrastructure. > > > Alex There's no specific concern really. One can in theory move the code handling !VIRTIO_F_ACCESS_PLATFORM such that instead of having a branch in virtio code, you instead override platform DMA API and then use DMA API unconditionally. The gain from that will probably be marginal, but maybe I'm wrong. Let's see the patches. We still need to do the override when !VIRTIO_F_ACCESS_PLATFORM, according to spec. Encrypted hypervisors still need to set VIRTIO_F_ACCESS_PLATFORM. Is VIRTIO_F_ACCESS_PLATFORM a good default? Need to support legacy guests does not allow that at the qemu level, we need to be conservative there. But yes, if you have a very modern guest then it might be a good idea to just always enable VIRTIO_F_ACCESS_PLATFORM. I say might since unfortunately most people only use VIRTIO_F_ACCESS_PLATFORM with vIOMMU, using it without VIRTIO_F_ACCESS_PLATFORM is supported but is a path less well trodden. Benchmarking that, fixing issues that surface if any would be imho effort well spent, and would be a prerequisite to making it a default in a production system. > > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > >
