On 21/05/2025 2:01 am, Christopher Clark wrote: > On Tue, May 20, 2025 at 3:10 PM Andrew Cooper > <andrew.coop...@citrix.com> wrote: > > Treat "argo" on the command line as a positive boolean, rather > than requiring > the user to pass "argo=1/on/enable/true". > > Move both opt_argo* variables into __ro_after_init. They're set > during > command line parsing and never modified thereafter. > > > Instead of binding to static values set at boot, would > boolean_runtime_param be acceptable?
No, for several reasons. Sure, you could dynamically turn it on, but existing domains can't use it because argo_init() wasn't called on them. Now consider what happens when dynamically turning it off behind the back of a domain which was using it. All the existing runtime controls are for properties that are not visible to guests. Adding opt_argo to this list would create a lot of carnage. (Like almost everything else in Xen), Argo is entirely broken with respect to enumeration and controls. And while this isn't your fault for having copied the status quo, it is still a problem needing fixing. Argo's availability needs advertising to the toolstack like all other features, and the toolstack needs to be able to choose the Argo settings on a per-VM basis. Like everything else about VMs, the Argo-ness must be invariant for the lifetime of the domain. This means changes to sysctls/domctls, which IMO are prerequisites for Argo to move from Tech Preview to Supported. In a world where such controls existed, the argo cmdline option would really only be for someone trying to disable Argo globally. This particular patch comes simply from me trying to experiment with Argo to sort out the XTF test, and deciding that the behaviour was objectionable enough that I'd improve it. ~Andrew
