Append extra device model args from xenstore (if present)

[timemaster5]

This allows for custom qemu process command-line parameters. Xenstore already provides a place for this but qemu-wrapper ignores it.

[last-genius]

Thanks for the PR (and the description of your use case in the associated issue).

This fork internally serves as a staging ground for PRs to the upstream xapi-project/xen-api repo and we do not usually accept contributions here - could you open a PR upstream instead? If not, we can try to carry this work forward ourselves by suggesting it upstream.

What do you mean by "Xenstore already provides a place for this but qemu-wrapper ignores it"? ~/platform/device_model_args is not one of the documented paths upstream (https://xenbits.xen.org/docs/unstable/misc/xenstore-paths.html), nor is it created as an empty directory by any toolstacks that I know of.

Which version of xapi are you running? If it's >25.38.0, then this fix should be included: xapi-project@930ffb3, I'd have expected it to resolve your issue. If not, then we could investigate why - but this automatic handling would be the preferred way of solving this, rather than piling on more platform arguments.

[timemaster5]

@last-genius thank you for response..

Thanks for the PR (and the description of your use case in the associated issue).

This fork internally serves as a staging ground for PRs to the upstream xapi-project/xen-api repo and we do not usually accept contributions here - could you open a PR upstream instead? If not, we can try to carry this work forward ourselves by suggesting it upstream.

No problem, I can open another PR there, if that makes sense, but maybe let's discuss first whether this is the right approach. Seems like it is not.

What do you mean by "Xenstore already provides a place for this but qemu-wrapper ignores it"? ~/platform/device_model_args is not one of the documented paths upstream (https://xenbits.xen.org/docs/unstable/misc/xenstore-paths.html), nor is it created as an empty directory by any toolstacks that I know of.

Ok, did a fact check and on my test machine it was there when I listed all arguments with xe vm-param-list, probably leftover from previous tests. Haven't checked an unmodified machine.
Sorry for that I will update this statement everywhere.

Which version of xapi are you running? If it's >25.38.0, then this fix should be included: xapi-project@930ffb3, I'd have expected it to resolve your issue. If not, then we could investigate why - but this automatic handling would be the preferred way of solving this, rather than piling on more platform arguments.

I agree. I am on xapi: 25.33 now; it seems like we have a new update in xcp-ng available of 26.1.3.
I will check again after I upgrade. The commit you pointed out seems interesting.

The main issue still could be that I don't see a way of setting up a romfile argument even when rombar is enabled and working. Or at least I am lacking knowledge of how the QMP messages are assembled for these dynamic tasks.

I've used another QEMU argument for it: -global xen_pci_passthrough.romfile, which is obviously wrong, but the fact I was able to pass anything custom was helpful. I've been able to set up rombar via QMP as well, but wasn't sure about timing and whether it worked or not, as the VM didn't see anything… which was caused by a broken implementation fixed in the commit you mentioned.

I still think it can be beneficial to have the option to modify the QEMU command line parameters.

[timemaster5]

I upgraded my machine, and the patch didn't help. Meaning it is probably working, but happened exactly what I was afraid of.

We still need to set ROMfile and ROMbar parameters, which is impossible to do via QMP after the machine is running because the device has been already initialised (realised):

{"error": {"class": "GenericError", "desc": "Attempt to set property 'romfile' on device 'pci-pt-01_00.0' (type 'xen-pci-passthrough') after it was realised"}}

If I know where to modify what QMP command is being sent on vm-start, I might be able to find a better place to put this setting at.

At this point the only viable option for me is to use QEMU command line arguments, and using either -global xen-pci-passthrough.romfile=FILENAME option, assuming it doesn’t break anything else, or in a more controlled way pass -device loader and put vBIOS to a correct location in memory which doesn’t affect other devices