[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [RFC] content: tweak VIRTIO_F_IO_BARRIER
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]