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@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);
+
     if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
         goto error;
 
@@ -7783,10 +7787,6 @@ qemuProcessReconnect(void *opaque)
     if (qemuDomainMasterKeyReadFile(priv) < 0)
         goto error;
 
-    /* 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);
-
     if (qemuHostdevUpdateActiveDomainDevices(driver, obj->def) < 0)
         goto error;
 
-- 
2.17.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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@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.

> +
>      if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
>          goto error;
>  
> @@ -7783,10 +7787,6 @@ qemuProcessReconnect(void *opaque)
>      if (qemuDomainMasterKeyReadFile(priv) < 0)
>          goto error;
>  
> -    /* 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);
> -
>      if (qemuHostdevUpdateActiveDomainDevices(driver, obj->def) < 0)
>          goto error;
>  
> 

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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@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.

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.

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.

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.

Tks -

John

>> +
>>      if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
>>          goto error;
>>  
>> @@ -7783,10 +7787,6 @@ qemuProcessReconnect(void *opaque)
>>      if (qemuDomainMasterKeyReadFile(priv) < 0)
>>          goto error;
>>  
>> -    /* 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);
>> -
>>      if (qemuHostdevUpdateActiveDomainDevices(driver, obj->def) < 0)
>>          goto error;
>>  
>>
> 
> Michal
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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@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).

> 
> 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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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@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
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list