search for: platform_access

...en_vring_use_dma()) > > return true; > > > > > > xen_vring_use_dma would be implemented so that it returns true when > > xen_swiotlb is required and false otherwise. > > Just to stress - with a patch like this virtio can *still* use DMA API > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms > as you seem to be saying, you guys should fix it before doing something > like this.. Yes, DMA API is broken with some interfaces (specifically: rpmesg and trusty), but for them PLATFORM_ACCESS is never set. That is why the errors weren'...

...en_vring_use_dma()) > > return true; > > > > > > xen_vring_use_dma would be implemented so that it returns true when > > xen_swiotlb is required and false otherwise. > > Just to stress - with a patch like this virtio can *still* use DMA API > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms > as you seem to be saying, you guys should fix it before doing something > like this.. Yes, DMA API is broken with some interfaces (specifically: rpmesg and trusty), but for them PLATFORM_ACCESS is never set. That is why the errors weren'...

On Wed, 1 Jul 2020, Christoph Hellwig wrote: > On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote: > > > I could imagine some future Xen hosts setting a flag somewhere in the > > > platform capability saying "no xen specific flag, rely on > > > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > > > How about

On Wed, 1 Jul 2020, Christoph Hellwig wrote: > On Mon, Jun 29, 2020 at 04:46:09PM -0700, Stefano Stabellini wrote: > > > I could imagine some future Xen hosts setting a flag somewhere in the > > > platform capability saying "no xen specific flag, rely on > > > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > > > How about

...return true; > > > > > > > > > xen_vring_use_dma would be implemented so that it returns true when > > > xen_swiotlb is required and false otherwise. > > > > Just to stress - with a patch like this virtio can *still* use DMA API > > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms > > as you seem to be saying, you guys should fix it before doing something > > like this.. > > Yes, DMA API is broken with some interfaces (specifically: rpmesg and > trusty), but for them PLATFORM_ACCESS is never set. That is...

...missing is an extremely > strong wording that says you SHOULD always set this flag for new > hosts, including an explanation why. So as far as power is concerned, IIUC the issue they are struggling with is that some platforms do not support pass-through mode in the emulated IOMMU. Disabling PLATFORM_ACCESS is so far a way around that, unfortunately just for virtio devices. I would like virtio-iommu to be able to address that need as well. -- MST

...tarted this thread: > > if (xen_vring_use_dma()) > return true; > > > xen_vring_use_dma would be implemented so that it returns true when > xen_swiotlb is required and false otherwise. Just to stress - with a patch like this virtio can *still* use DMA API if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms as you seem to be saying, you guys should fix it before doing something like this.. -- MST

...gt; > but can it be modified or expanded? > > I think the important point is that for some cases there is no need > to dma map at all, and upper layers should be fine by that by just > doing the dma mapping in helpers called by the driver. > > The virtio drivers then check if platform_access is set, then call the > generic dma mapping helper, or if not just allocate memory using > alloc_pages and also skip all the sync calls. In theory, absolutely. In practice modern virtio devices are ok, the reason we are stuck supporting old legacy ones is because legacy devices are needed to...