Re: [virtio-dev] Re: [RFC] content: tweak VIRTIO_F_IO_BARRIER

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jul 16, 2018 at 07:04:19PM +0800, Tiwei Bie wrote:
> > > > So, do we still consider VIRTIO_F_IO_BARRIER useful with its current
> > > > definition? Do we need to clarify assumptions, start afresh, or add a
> > > > new feature? This is not clear to me from the discussion.
> > > 
> > > The discussion is to talk about how to fix the potential
> > > problems that currently may happen when the virtio devices
> > > (which need to bypass the IOMMU) work on the platforms
> > > (which have DMA limitations).
> > > 
> > > Currently,
> > > 
> > > - IO_BARRIER is just to tell drivers which type of barriers
> > >   should be used.
> > > 
> > > - IOMMU_PLATFORM (from my understanding) is to tell drivers
> > >   whether the devices need to bypass the IOMMU.
> > > 
> > > Michael is asking whether we should tweak above two bits
> > > or whether we should do something else to solve this problem.
> > > 
> > > If we want to tweak above two bits, they may become
> > > something like:
> > > 
> > > - PLATFORM_CACHE (from IO_BARRIER): about the memory
> > >    operations visibility between driver and device.
> 
> Should the driver always try to determine device's
> DMA-coherence in the platform specific way?

Point is, some systems don't have any PV interfaces
besides virtio. These need a virtio way to discover
coherence as long as we don't emulate the more expensive
platform specific one.

> > > 
> > > - PLATFORM_IOMMU (from IOMMU_PLATFORM):
> > 
> > I'm not sure we necessarily need to swap the name
> > around like that.
> > 
> > > about whether
> > >    the DMA addr passed to the device should be prepared
> > >    (because e.g. the device is behind an IOMMU, or the
> > >    device can only access parts of system memory).
> 
> For the case that device can only access parts of system
> memory, if we need virtio device to support this, it seems
> that we also need to provide a way for virtio driver to
> know the inaccessible memory range?

I guess at this point people seem to be happy with
a platform-specific way to discover this.

> > 
> > Maybe we want to also include the case where device IO
> > addresses don't match physical addresses (e.g. include
> > an offset).
> > 
> >
> 
> It seems that above idea doesn't fix all the problems,
> e.g. the case mentioned by Jason, that virtio driver
> cannot use swiotlb (which is transparent to the device)
> when the IOMMU_PLATFORM bit isn't offered by the device.

Right so is this a real use-case?
Are there platforms where
- it is hard to make virtio appear not behind an iommu
- iommu can not support a passthrough mode
- virtio addressing needs to be limited






-- 
MST

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org