On a Friday in 2025, Nathan Chen wrote:
On 11/7/2025 4:40 AM, Ján Tomko wrote:
On a Thursday in 2025, Nathan Chen wrote:
On 11/6/2025 11:19 AM, Ján Tomko wrote:
Open iommufd FDs from libvirt backend without exposing these FDs to XML users, i.e. one per domain for /dev/iommu and one per iommufd hostdev for /dev/vfio/devices/vfioX, and pass the FD to qemu command line.
The part formatting the object and the part formatting the device should be split.
Sounds good, I will split it into two commits. >> Signed-off-by: Nathan Chen <nathanc@nvidia.com>
--- src/qemu/qemu_command.c | 43 +++++++- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 8 ++ src/qemu/qemu_domain.h | 7 ++ src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_process.c | 232 ++++++++++++++++++++++++++++++++++++++++ 6 files changed, 289 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 8fd7527645..740a6970f2 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -4730,7 +4730,8 @@ qemuBuildVideoCommandLine(virCommand *cmd,
virJSONValue * qemuBuildPCIHostdevDevProps(const virDomainDef *def, - virDomainHostdevDef *dev) + virDomainHostdevDef *dev, + virDomainObj *vm)
Hmm, perhaps exposing the iommufd object in the XML would save us from having to pass this.
We are passing virDomainObj to this function in order to retrieve the FD number, would you mind clarifying how we could avoid passing this by exposing the iommufd object in the XML? It is my understanding that exposing the iommufd object ID would still mean we need pass the virDomainObj.
If it was a separate device, it would have its own data type and own formatting function unrelated to hostdevs.
That makes sense, like passing a new virDomainIommufdDef struct pointer to a new qemuBuildIommufdDevProps() function. Previously we implemented a virDomainIommufdDef struct as a member under virDomainIOMMUDef [0] to store the iommufd ID and FD number. But we changed the implementation adn XML representation to only be a bool member associated with hostdevs. What are your thoughts on either of the following paths forward?
1. Re-implementing the virDomainIommufdDef struct as a virDomainHostdevDef member, storing the FD numbers as part of a private data struct member in virDomainIommufdDef 2. Storing the FD numbers as part of a private data struct member in virDomainHostdevDef, and avoiding implementing a separate virDomainIommufdDef struct.
Option 2 seems the most straightforward t ome, still allowing us to avoid passing the virDomainObj to qemuBuildPCIHostdevDevPRops(), but please let me know what you think.
Oops, I missed this question. Option 2 sounds better to me. Jano
[0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/EASBQ...
Thanks, Nathan