Re: [libvirt] [PATCH v2 1/3] qemu: Move allow reboot check setting
On 11/6/18 7:48 AM, Michal Privoznik wrote:
On 11/06/2018 01:28 PM, John Ferlan wrote:
>
>
> On 11/6/18 4:38 AM, Michal Privoznik wrote:
>> On 11/01/2018 05:04 PM, John Ferlan wrote:
>>> Checking and setting the priv->allowReboot can be done before we start
>>> processing the job. A subsequent patch will make use of the value to
>>> make decisions in the error label, so we need to have it set properly.
>>>
>>> Signed-off-by: John Ferlan <jferlan(a)redhat.com>
>>> ---
>>> src/qemu/qemu_process.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
>>> index 9cf971808c..5232f761af 100644
>>> --- a/src/qemu/qemu_process.c
>>> +++ b/src/qemu/qemu_process.c
>>> @@ -7767,6 +7767,10 @@ qemuProcessReconnect(void *opaque)
>>> cfg = virQEMUDriverGetConfig(driver);
>>> priv = obj->privateData;
>>>
>>> + /* If we are connecting to a guest started by old libvirt there is no
>>> + * allowReboot in status XML and we need to initialize it. */
>>> + qemuProcessPrepareAllowReboot(obj);
>>
>> I'm not quite sure why this happens outside of job. It doesn't look like
>> it has to.
>>
>
> Is there a reason in your opinion it needs to occur inside a job? It is
> a void function.
The type of the return value doesn't matter.
qemuProcessPrepareAllowReboot() changes private data and that is
potentially dangerous if done outside modify job (even though the @vm is
locked at this point so I guess it is not that dangerous after all).
Does that mean we need to cull the code looking for everywhere in the
code where @priv data is modified outside a job? and start a job if so?
I thought jobs were more related to monitor interactions rather than
@priv modification.
The answer still doesn't make sense to me.
John
>
> It's moved to prior to the first "goto error" because of patch3 which
> would call qemuDomainIsUsingNoShutdown which checks priv->allowReboot
> which is possibly set in *AllowReboot. Without that move, the code would
> need to be reworked, which is fine, but understanding the reason why I
> wrote things the way I did is important, IMO. I can add a comment to
> "warn" the next person trying to move it that the error: logic uses the
> ->allowReboot value.
>
> The allowReboot alteration has nothing to do with a job AFAICT and
> whether on error: there is a job or not. Perhaps no different to what
> qemuDomainObjRestoreJob is doing by using @priv fields for @oldjob.
Yeah, but RestoreJob is special - we can't call it after job is
acquired, we want to save currently running job to a temp variable so
that we can start a new job.
>
> Although looking at and quickly thinking about the code now, I wonder if
> the virQEMUDriverGetCapabilities and goto error should be inside a job
> too since error would then call qemuProcessStop without being in a job.
Ooops, yes.
>
> If this is dropped then logic in patch3 needs to be altered in order to
> account for jobStarted = true... I think that got too messy when I first
> thought about it.
Michal