iommufd fault queue #24
Conversation
tools/vfntool/vfntool.c
Outdated
|
|
||
| static struct opt_table opts[] = { | ||
| OPT_WITHOUT_ARG("-h|--help", opt_set_bool, &show_usage, "show usage"), | ||
| OPT_WITHOUT_ARG("-v|--verbose", opt_set_bool, &verbose, "verbose"), | ||
|
|
||
| OPT_WITH_ARG("-d|--device BDF", opt_set_charp, opt_show_charp, &bdf, "pci device"), | ||
| OPT_WITHOUT_ARG("-x|--reset", opt_set_bool, &reset, "reset"), | ||
| OPT_WITH_ARG("-t|--target DRIVER", opt_set_charp, opt_show_charp, &target, "bind to DRIVER"), |
There was a problem hiding this comment.
This has a hit on the checkpatch script. You think you just need to line break before "bind to DRIVER"),
| @@ -49,6 +50,7 @@ struct iommufd_device_info { | |||
|
|
|||
| int dev_fd; | |||
| int dev_id; | |||
| int hwpt_id; | |||
There was a problem hiding this comment.
Do we really need hwpt_id?
The hwpt_id is used immediately after it is produced to never be used again in
libvfn. It is relevant for the Linux Kernel in the following calls:
- IOMMU_HWPT_SET_DIRT_TRACKING
- IOMMU_HWPT_GET_DIRTY_BITMAP
- IOMMU_HWPT_INVALIDATE
Should we just not have it until we need it?
There was a problem hiding this comment.
Since we do not expose struct iommufd_device_info in the public headers, I see why we could get away with not storing it. We do not even need it for detaching.
There was a problem hiding this comment.
I would just remove it/comment it out until the time that it is needed.
|
|
||
| attach_cmd.pt_id = hwpt_alloc_cmd.out_hwpt_id; | ||
|
|
||
| if (ioctl(devfd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, &attach_cmd)) { |
There was a problem hiding this comment.
What about VFIO_DEVICE_DETACH_IOMMUFD_PT
At the moment the way to use the IOPF functionality in libvfn is by using a
VFIO_DEVICE_ATTACH_IOMMUFD_PT ioctl and then it is detached when the pci
device is closed. Couple of questions here:
- Do we see that the user will always have to close the PCI device to detach
the hwpt? What happens if the user needs to connect to another hwpt or just
needs another one? - Does it make sense to think about providing a way to detach the hwpt without
closing the pci device? - Notice that this is more like a general comment regarding VFIO_DEVICE_ATTACH_IOMMUFD_PT than for this line
There was a problem hiding this comment.
I think it would be nice to provide that functionality. How to do that I am not sure. This series suggests to add an iommufd specific header file vfn/iommu/iommufd.h since this functionality is tied to iommufd and not generic like the rest of the API in vfn/iommu.h. In lieu of that, detaching could (should) be provided as well.
There was a problem hiding this comment.
Based on what we discussed offline, I would not implement a detach and leave it for when you have more information on how the library is being used.
birkelund
force-pushed
the
iommufd-fault-queue
branch
from
6f3c5d1 to
c7b5695
Compare
Only check that the target device is an NVMe device when binding to the nvme driver. Signed-off-by: Klaus Jensen <[email protected]>
One might need to point the build to a linux kernel include directory different from the one that is currently installed. To avoid having to constantly install the linux kernel headers on the system, add a meson build option that adds a user defined path to the include paths of the project. Signed-off-by: Joel Granados <[email protected]> [k.jensen: refactor] Signed-off-by: Klaus Jensen <[email protected]>
Add an internal list to keep track of devices that have been binded to iommufd. Signed-off-by: Klaus Jensen <[email protected]>
Add support for iommufd based fault queues. Signed-off-by: Joel Granados <[email protected]> [k.jensen: refactored] Signed-off-by: Klaus Jensen <[email protected]>
Add example using the iommufd fault queue to handle device page faults. This example is intended to be used with the QEMU pcie-ats-testdev device. See QEMU for documentation. Signed-off-by: Klaus Jensen <[email protected]>
birkelund
force-pushed
the
iommufd-fault-queue
branch
from
c7b5695 to
2b9a073
Compare
No description provided.