On Fri, 16 Oct 2020, Arnd Bergmann via Stratos-dev wrote:

On Fri, Oct 16, 2020 at 9:19 AM Jean-Philippe Brucker jean-philippe@linaro.org wrote:

...

On Fri, Oct 02, 2020 at 04:26:10PM +0200, Arnd Bergmann wrote:

...

...

At the moment the bounce buffer is allocated from a global pool in the low physical pages. However a recent proposal by Chromium would add support for per-device swiotlb pools:

https://lore.kernel.org/linux-iommu/20200728050140.996974-1-tientzu@chromium...

And quoting Tomasz from the discussion on patch 4:

    For this, I'd like to propose a "restricted-dma-region" (feel free
    to suggest a better name) binding, which is explicitly specified
    to be the only DMA-able memory for this device and make Linux use
    the given pool for coherent DMA allocations and bouncing
    non-coherent DMA.

Right, I think this can work, but there are very substantial downsides to it:

• it is a fairly substantial departure from the virtio specification, which defines that transfers can be made to any part of the guest physical address space

Coming back to this point, that was originally true but prevented implementing hardware virtio devices or putting a vIOMMU in front of the device. The spec now defines feature bit VIRTIO_F_ACCESS_PLATFORM (previously called VIRTIO_F_IOMMU_PLATFORM):

A device SHOULD offer VIRTIO_F_ACCESS_PLATFORM if its access to memory is through bus addresses distinct from and translated by the platform to physical addresses used by the driver, and/or if it can only access certain memory addresses with said access specified and/or granted by the platform. A device MAY fail to operate further if VIRTIO_F_ACCESS_PLATFORM is not accepted.

With this the driver has to follow the DMA layout given by the platform, in our case given by the device tree.

Ok, got it.

...

Another point about solution #1: since the backend (secondary VM) accesses virtqueue directly (we probably want to avoid a scatter-gather translation step in the backend) the pointers written by the frontent in the virtqueue have to be guest-physical addresses of the backend. So the static memory region needs to have identical guest-physical address in primary and secondary VM. In practice I doubt this would be a problem.

I believe this is different from what Srivatsa explained in yesterday's call about Qualcomm's current work, which makes all pointer values relative to the start of the shared memory area, making them relocatable between frontend and backend guest physical address spaces.

Of course, as long as the backend is aware of the start address of the shared buffer at the frontend side, it can very easily add/subtract any offsets as required.

Disambiguation: - frontend: Linux virtio drivers, drivers/net/virtio_net.c - backend: QEMU