On 11/7/24 3:31 PM, Nicolin Chen wrote:
Hi Eric,
On Thu, Nov 07, 2024 at 12:11:05PM +0100, Eric Auger wrote:
On 11/1/24 05:09, Nicolin Chen wrote:
Hi,
This is a continued discussion following previous month's:
https://lore.kernel.org/qemu-devel/Zvr%2Fbf7KgLN1cjOl@Asurada-Nvidia/
Kernel changes are getting closer to merge, as Jason's planning to
take vIOMMU series and smmuv3_nesting series into the iommufd tree:
https://lore.kernel.org/all/cover.1730313494.git.nicol...@nvidia.com/
https://lore.kernel.org/all/cover.1730313494.git.nicol...@nvidia.com/
https://lore.kernel.org/all/0-v4-9e99b76f3518+3a8-smmuv3_nesting_...@nvidia.com/
So, I think it's probably a good time to align with each others and
talk about kicking off some QEMU upstream work in the month ahead.
@Shameer,
Do you have some update on the pluggable smmuv3 module?
Updates on my side:
1) I have kept uAPI updated to the latest version and verified too.
There should be some polishing changes depending on how the basic
nesting infrastructure would look like from Intel/Duan's work.
2) I got some help from NVIDIA folks for the libvirt task. And they
have done some drafting and are now verifying the PCI topology
with "iommu=none".
Once the pluggable smmuv3 module is ready to test, we will make some
change to libvirt for that and drop the auto-assigning patches from
the VIRT code, so as to converge for a libvirt+QEMU test.
FWIW, Robin requested a different solution for MSI mapping [1], v.s.
the RMR one that we have been using since Eric's work. I drafted a
few VFIO/IOMMUFD patches for that, yet paused for getting the vIOMMU
series merged to this kernel cycle. I plan to continue in Nov/Dec.
So, for the near term we will continue with the RMR solution, until
we have something solid later.
[1] https://lore.kernel.org/linux-iommu/ZrVN05VylFq8lK4q@Asurada-Nvidia/
At Red Hat we may find some cycles to resume working on the QEMU
integration. Please can you sketch some tasks we could carry out in
coordination with you and Shameer? Adding Don in the loop.
That is great!
So, given that Shameer is working on pluggable module part and we
have folks working on libvirt. I think the only big thing here is
the SMMUv3 series itself. Please refer to the changes in the link:
- cover-letter: Add HW accelerated nesting support for arm SMMUv3
- https://github.com/nicolinc/qemu/commits/wip/for_smmuv3_nesting-v4/
I expect the IOMMU_HWPT_ALLOC (backend APIs) will go with Intel's
series once their current "emulated devices" one gets merged. And
I think I can prepare IOMMU_VIOMMU_ALLOC patches for backend APIs
aligning with HWPT's.
That being said, one thing I am not sure is how we should bridge
between these backend APIs and a virtual IOMMUs (vSMMU/intel). I
think it'd be better for you and Red Hat to provide some insight,
if calling the backend APIs directly from a viommu module isn't a
preferable way.
We also need your comments on vSMMU module patches that are still
roughly a draft requiring a rework at some small details I think.
So, if your (and Don's) bandwidth allows, perhaps you could take
over the vSMMU patches? Otherwise, we can also share the task for
reworking.
Thanks!
Nicolin
Nicolin,
Hi!
Sounds like a plan. Glad to join the effort.
- Don
