On 2020/7/8 上午3:54, Peter Xu wrote:
On Tue, Jul 07, 2020 at 04:03:10PM +0800, Jason Wang wrote:
On 2020/7/3 下午9:03, Peter Xu wrote:
On Fri, Jul 03, 2020 at 03:24:19PM +0800, Jason Wang wrote:
On 2020/7/2 下午11:45, Peter Xu wrote:
On Thu, Jul 02, 2020 at 11:01:54AM +0800, Jason Wang wrote:
So I think we agree that a new notifier is needed?
Good to me, or a new flag should be easier (IOMMU_NOTIFIER_DEV_IOTLB)?
That should work but I wonder something as following is better.
Instead of introducing new flags, how about carry the type of event in the
notifier then the device (vhost) can choose the message it want to process
like:
static vhost_iommu_event(IOMMUNotifier *n, IOMMUTLBEvent *event)
{
switch (event->type) {
case IOMMU_MAP:
case IOMMU_UNMAP:
case IOMMU_DEV_IOTLB_UNMAP:
...
}
Looks ok to me, though imo we should still keep the registration information,
so VT-d knows which notifiers is interested in which events. E.g., we can
still do something like vtd_as_has_map_notifier().
Is this for a better performance?
I wonder whether it's worth since we can't not have both vhost and vtd to be
registered into the same as.
/me failed to follow this sentence.. :(
Sorry, I meant "vfio" instead "vtd".
So it should be functional equivalent to vtd_as_has_notifier().
For example: in vtd_iommu_replay() we'll skip the replay if vhost has
registered the iommu notifier because vtd_as_has_map_notifier() will return
false.
Two questions:
- Do we care the performance here? If not, vhost may just ignore the MAP
event?
- If we care the performance, it's better to implement the MAP event for
vhost, otherwise it could be a lot of IOTLB miss
Thanks
It'll only return true if the device is a vfio-pci device.
Without vtd_as_has_map_notifier(), how could we do that?
