qemu-wrapper ignores platform:device_model_args

[timemaster5]

I’ve recently been trying to add custom arguments to a qemu process.

I found the platform:device_model_args in xenstore which seemed like a suitable place to use.

However qemu-wrapper ignores these arguments. Is there another mechanism to achieve the same result in place?

[timemaster5]

pull request here if you feel like it :)
xcp-ng/xen-api#15

[stormi]

CC @xcp-ng/xapi-network

[stormi]

@timemaster5 could you describe your use case?

[timemaster5]

thank you @stormi for looking into it, there are two perspectives to this.

From a general standpoint, there is currently no straightforward way to pass arbitrary arguments to QEMU through this layer, which could be considered a useful capability on its own. Having a controlled mechanism for extending QEMU invocation would make the system more flexible and adaptable to a wider range of use cases, not just the one described here. Also XenStore already contains this platform:device_model_args, they are just ignored.

From a more practical perspective, the immediate motivation is enabling AMD iGPU passthrough in scenarios where the existing abstractions are not sufficient. At the moment, the only viable path is to pass the VBIOS into the VM so that amdgpu can properly initialize the device by utilizing -device loader. An originally intended xen_pci_passthrough.romfile and rombar options are currently not functional.

This proposal is therefore not just a workaround for a single issue, but a step toward unlocking a broader class of configurations that are currently difficult or impossible to achieve. Even beyond GPU passthrough, having the ability to extend QEMU arguments in a structured way could support other advanced or experimental setups without requiring invasive changes elsewhere.

For additional context, I have documented the specific use case and limitations here:
https://medium.com/@timemaster5/getting-amd-phoenix-igpu-passthrough-working-on-xen-xcp-ng-8856593f9c0d

[stormi]

Thanks for the detailed answer. iGPU pass-through is an interesting use case, for sure. I don't know about the exact technical changes that you suggest, but I'll CC our @xcp-ng/hypervisor-kernel team to get their opinion about the proper way to achieve it.

[fallen]

Hello @timemaster5 do you still need this since now ROM expansion BAR are available in the guest VM?

[timemaster5]

@fallen yes, please. The ROM BAR fix is only part of the story; it doesn’t resolve the whole issue on its own.

But I would suggest renaming this issue, perhaps.
Later on, I learned that device_model_args is not a standard, documented XenStore option.

This means the issue is not that qemu-wrapper ignores it, but rather that we don’t have a standardized way of manipulating QEMU parameters other than those defined in XAPI. This can be limiting in some edge cases.

Even VMware ESXi—where it often feels like you can’t change much—allowed users to define options via advanced settings. These were often unsupported and experimental, but they could still be very helpful when there wasn’t time or budget to upgrade the entire stack, and there was a sudden need, for example with Windows 10 back then, for a customized VM BIOS and similar adjustments.

It doesn’t feel right to assume we can define all the best possible QEMU options and combinations for every use case, and at the same time restrict users from applying their own.

QEMU is a separate project and far broader than the subset we use in XCP-ng. Hiding that flexibility or downplaying its role doesn’t make much sense...