Drop redundant resume_all_vcpus from main

PATCH In review Jan Kiszka 3 participants 6 messages Aug 20, 2012 – May 2, 2013

Share & tools

Jan Kiszka

author

2012-08-20 18:11 UTC #0 lore raw

PATCH 1/1 Drop redundant resume_all_vcpus from main

VCPUs are either resumed directly via vm_start, after the incoming migration is done, or when a continue command is issued. We don't need the explicit resume before entering main_loop.

Signed-off-by Jan Kiszka <[email protected]>

---

I was adding nesting support to pause/resume_all_vcpus, and that stumbled over the imbalance below.

 vl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

vl.c +0 -1

index ebee867..231d3ab 100644
@@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
 
     os_setup_post();
 
-    resume_all_vcpus();
     main_loop();
     bdrv_close_all();
     pause_all_vcpus();

Signature · 1 line

1.7.3.4

Paolo Bonzini

2012-08-21 07:01 UTC #1 lore raw

Il 20/08/2012 20:11, Jan Kiszka ha scritto:

Quoted 19 lines

VCPUs are either resumed directly via vm_start, after the incoming migration is done, or when a continue command is issued. We don't need the explicit resume before entering main_loop.
Signed-off-by Jan Kiszka <[email protected]>
---
I was adding nesting support to pause/resume_all_vcpus, and that stumbled over the imbalance below.
 vl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
vl.c +0 -0
index ebee867..231d3ab 100644

vl.c int main(int argc, char **argv, char **envp) · line 3762

Quoted 7 lines

vl.c +0 -1

@@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
 
     os_setup_post();
 
-    resume_all_vcpus();
     main_loop();
     bdrv_close_all();
     pause_all_vcpus();

Makes sense. Do we need a "main loop and similar" tree, or can that tree be just uq/master now that qemu-kvm.c is dying?

Paolo

Jan Kiszka

author

2012-08-21 07:24 UTC #2 lore raw

Quoted 22 lines · Paolo Bonzini

Il 20/08/2012 20:11, Jan Kiszka ha scritto:
Quoted 21 lines
VCPUs are either resumed directly via vm_start, after the incoming migration is done, or when a continue command is issued. We don't need the explicit resume before entering main_loop.
Signed-off-by Jan Kiszka <[email protected]>
---
I was adding nesting support to pause/resume_all_vcpus, and that stumbled over the imbalance below.
 vl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
vl.c +0 -0
index ebee867..231d3ab 100644
@@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
 
     os_setup_post();
 

Quoted 8 lines

vl.c int main(int argc, char **argv, char **envp) · line 3762
Quoted 5 lines
vl.c +0 -1
-    resume_all_vcpus();
     main_loop();
     bdrv_close_all();
     pause_all_vcpus();
Makes sense. Do we need a "main loop and similar" tree, or can that tree be just uq/master now that qemu-kvm.c is dying?

I'm not sure if this qualifies for uq/master. On the other hand, all the efforts to refactor locking and make QEMU more scalable would like be happy to have a home. Can be uq/master, but they will not only affect KVM in the end.

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Jan Kiszka

author

2013-05-02 11:20 UTC #3 lore raw

In reply to Paolo Bonzini

Quoted 31 lines · Paolo Bonzini

Il 20/08/2012 20:11, Jan Kiszka ha scritto:
Quoted 19 lines
VCPUs are either resumed directly via vm_start, after the incoming migration is done, or when a continue command is issued. We don't need the explicit resume before entering main_loop.
Signed-off-by Jan Kiszka <[email protected]>
---
I was adding nesting support to pause/resume_all_vcpus, and that stumbled over the imbalance below.
 vl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
vl.c +0 -0
index ebee867..231d3ab 100644
vl.c int main(int argc, char **argv, char **envp) · line 3762
Quoted 7 lines
vl.c +0 -1
@@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
 
     os_setup_post();
 
-    resume_all_vcpus();
     main_loop();
     bdrv_close_all();
     pause_all_vcpus();
Makes sense. Do we need a "main loop and similar" tree, or can that tree be just uq/master now that qemu-kvm.c is dying?

Quoted 2 lines

Paolo

Just noticed that this cleanup didn't make it into upstream back then. Not truly trivial, but also not really risky.

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Andreas Färber

2013-05-02 11:55 UTC #4 lore raw

Am 02.05.2013 13:20, schrieb Jan Kiszka:

Quoted 32 lines · Paolo Bonzini

Quoted 22 lines
Il 20/08/2012 20:11, Jan Kiszka ha scritto:
Quoted 21 lines
VCPUs are either resumed directly via vm_start, after the incoming migration is done, or when a continue command is issued. We don't need the explicit resume before entering main_loop.
Signed-off-by Jan Kiszka <[email protected]>
---
I was adding nesting support to pause/resume_all_vcpus, and that stumbled over the imbalance below.
 vl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
vl.c +0 -0
index ebee867..231d3ab 100644
@@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
 
     os_setup_post();
 
Quoted 8 lines
vl.c int main(int argc, char **argv, char **envp) · line 3762
Quoted 5 lines
vl.c +0 -1
-    resume_all_vcpus();
     main_loop();
     bdrv_close_all();
     pause_all_vcpus();
Makes sense. Do we need a "main loop and similar" tree, or can that tree be just uq/master now that qemu-kvm.c is dying?

Quoted 2 lines

Just noticed that this cleanup didn't make it into upstream back then. Not truly trivial, but also not really risky.

Since I happened to touch that CPU function just yesterday and Paolo and me seem to agree the call is superfluous, applying it to qom-cpu:

https://github.com/afaerber/qemu-cpu/commits/qom-cpu

Thanks,
Andreas

Signature · 2 lines

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Jan Kiszka

author

2013-05-02 12:06 UTC #5 lore raw

Quoted 33 lines · Andreas Färber

Am 02.05.2013 13:20, schrieb Jan Kiszka:
Quoted 32 lines · Paolo Bonzini
Quoted 30 lines
Il 20/08/2012 20:11, Jan Kiszka ha scritto:
Quoted 19 lines
VCPUs are either resumed directly via vm_start, after the incoming migration is done, or when a continue command is issued. We don't need the explicit resume before entering main_loop.
Signed-off-by Jan Kiszka <[email protected]>
---
I was adding nesting support to pause/resume_all_vcpus, and that stumbled over the imbalance below.
 vl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
vl.c +0 -0
index ebee867..231d3ab 100644
vl.c int main(int argc, char **argv, char **envp) · line 3762
Quoted 7 lines
vl.c +0 -1
@@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
 
     os_setup_post();
 
-    resume_all_vcpus();
     main_loop();
     bdrv_close_all();
     pause_all_vcpus();
Makes sense. Do we need a "main loop and similar" tree, or can that tree be just uq/master now that qemu-kvm.c is dying?

Quoted 7 lines

Quoted 2 lines
Just noticed that this cleanup didn't make it into upstream back then. Not truly trivial, but also not really risky.
Since I happened to touch that CPU function just yesterday and Paolo and me seem to agree the call is superfluous, applying it to qom-cpu:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

Perfect!

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux