[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 2018年06月29日 12:21, Michael S. Tsirkin wrote:
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.One issue here is sometime we may have something like a software IOTLB which is transparent to device. Just infer from the name of PLATFORM_CACHE, it seems does not cover this case.I don't think device needs to know about that. That's up to driver/OS.
So the question is can driver get those limitations or requirements through a transport specific way instead of depending a feature. If we define a feature that does not cover all the cases, we probably need another one to fix it. That's suboptimal.
- PLATFORM_IOMMU (from IOMMU_PLATFORM): 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).So I think it's a bug of driver instead of a missing feature.what is?
I mean it was probably a bug that we must specify PLATFORM_IOMMU to use swiotlb.
We can even fail the device probe in this case for safety. Thanksdevice can and does.
Yes. Thanks
Currently, I don't know what's the best choice.. Best regards, Tiwei Bie
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]