On 5/13/21 7:43 PM, Paolo Bonzini wrote:
On 13/05/21 10:25, Mirela Grujic wrote:
The existing code had to be restructured to make room for adding
checks that are specific to the machine phases.

The fix is related to the way that commands with the 'allow-preconfig'
option are treated.

Commands labelled with the 'allow-preconfig' option were meant to be allowed
during the 'preconfig' state, i.e. before the machine is initialized.
The equivalent of 'preconfig' state (after its removal) is machine init
phase MACHINE_INIT_PHASE_ACCEL_CREATED. Therefore, commands with
'allow-preconfig' option should be allowed to run while the machine is
in MACHINE_INIT_PHASE_ACCEL_CREATED phase.
Before this patch, those commands were allowed to run if the machine is
not ready, which includes three more phases besides the accel-created
phase. Since there were no means to enter other phases via QMP, the
implementation was fine. However, with the introduction of
'next-machine-phase' and 'advance-machine-phase' commands, one could
enter machine 'initialized' phase and still have available 'preconfig'
commands, which is incorrect.

This patch makes available 'allow-preconfig' commands only when they're
needed - before the machine is initialized, in the accel-created phase.
To enable a command after the machine gets initialized and before it
becomes ready, one should use 'allow-init-config' option that will be
introduced in the following patch.

There aren't many commands that are valid only for the accel created or machine initialized phase.  I think adding allow-init-config is more churn than keeping only allow-preconfig, and calling phase_check in the individual commands.  (Or even better, in the internal APIs that they call, so that QMP is completely oblivious to phases and just gets the Error* back).

In other words, allow-preconfig is there because there are many commands that are allowed only after the machine-ready phase, but anything in the middle can be handled just fine from C code.


To summarize, 'allow-preconfig' specifies whether a command is allowed to run before the machine is ready, so any command that should be allowed to run at phase < 'machine-ready' must have this flag set. For those commands, one should check the current machine phase in the implementation of the command to determine whether the command should run or not, and return an error if not. Ok, that's fine.



Paolo


Reply via email to