* [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset()
@ 2016-04-04 4:49 David Gibson
2016-04-04 7:31 ` Paolo Bonzini
2016-04-04 8:24 ` Laurent Vivier
0 siblings, 2 replies; 5+ messages in thread
From: David Gibson @ 2016-04-04 4:49 UTC (permalink / raw)
To: pbonzini, peter.maydell
Cc: lvivier, mtosatti, agraf, qemu-devel, qemu-ppc, David Gibson
There are currently 3 calls to qemu_system_reset() in vl.c. Two of them
are immediately preceded by a cpu_synchronize_all_states9) and the
remaining one should be.
The one which doesn't is the very first reset called directly from main().
Without a cpu_synchronize_all_states(), kvm_vcpu_dirty is false at this
point from the earlier cpu_synchronize_all_post_init(). That's incorrect
because the reset path is quite likely to update the CPU state, and that
updated state should be pushed back to KVM, not overwritten with stale
data pushed to KVM immediately after init.
This patch moves the call to cpu_synchronize_all_states() into
qemu_system_reset() for safety, so it is always called. AFAICT this should
be safe for the handful of callers outside vl.c - these all appear to be in
places where the cpu state is already synchronized so the extra call
will be a no-op.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
vl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This fixes a real but on ppc - the incorrect state of kvm_vcpu_dirty
means that an extra cpu_synchronize_state() in revised code for
updating the MSR is not a no-op as expected and loads a stale MSR
value, resulting in an incorrect MSR value on entry to the guest.
Therefore, I'm hoping to apply this ASAP to 2.6.
Laurent, could you please verify that this does indeed address the
problem with an incorrect MSR on entry.
diff --git a/vl.c b/vl.c
index bd81ea9..3629336 100644
--- a/vl.c
+++ b/vl.c
@@ -1745,6 +1745,8 @@ void qemu_system_reset(bool report)
mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
+ cpu_synchronize_all_states();
+
if (mc && mc->reset) {
mc->reset();
} else {
@@ -1893,7 +1895,6 @@ static bool main_loop_should_exit(void)
}
if (qemu_reset_requested()) {
pause_all_vcpus();
- cpu_synchronize_all_states();
qemu_system_reset(VMRESET_REPORT);
resume_all_vcpus();
if (!runstate_check(RUN_STATE_RUNNING) &&
@@ -1903,7 +1904,6 @@ static bool main_loop_should_exit(void)
}
if (qemu_wakeup_requested()) {
pause_all_vcpus();
- cpu_synchronize_all_states();
qemu_system_reset(VMRESET_SILENT);
notifier_list_notify(&wakeup_notifiers, &wakeup_reason);
wakeup_reason = QEMU_WAKEUP_REASON_NONE;
--
2.5.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset()
2016-04-04 4:49 [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset() David Gibson
@ 2016-04-04 7:31 ` Paolo Bonzini
2016-04-04 7:54 ` David Gibson
2016-04-04 8:24 ` Laurent Vivier
1 sibling, 1 reply; 5+ messages in thread
From: Paolo Bonzini @ 2016-04-04 7:31 UTC (permalink / raw)
To: David Gibson, peter.maydell
Cc: lvivier, mtosatti, qemu-ppc, agraf, qemu-devel
On 04/04/2016 06:49, David Gibson wrote:
> There are currently 3 calls to qemu_system_reset() in vl.c. Two of them
> are immediately preceded by a cpu_synchronize_all_states9) and the
> remaining one should be.
>
> The one which doesn't is the very first reset called directly from main().
> Without a cpu_synchronize_all_states(), kvm_vcpu_dirty is false at this
> point from the earlier cpu_synchronize_all_post_init(). That's incorrect
> because the reset path is quite likely to update the CPU state, and that
> updated state should be pushed back to KVM, not overwritten with stale
> data pushed to KVM immediately after init.
>
> This patch moves the call to cpu_synchronize_all_states() into
> qemu_system_reset() for safety, so it is always called. AFAICT this should
> be safe for the handful of callers outside vl.c - these all appear to be in
> places where the cpu state is already synchronized so the extra call
> will be a no-op.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> vl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> This fixes a real but on ppc - the incorrect state of kvm_vcpu_dirty
> means that an extra cpu_synchronize_state() in revised code for
> updating the MSR is not a no-op as expected and loads a stale MSR
> value, resulting in an incorrect MSR value on entry to the guest.
>
> Therefore, I'm hoping to apply this ASAP to 2.6.
>
> Laurent, could you please verify that this does indeed address the
> problem with an incorrect MSR on entry.
>
> diff --git a/vl.c b/vl.c
> index bd81ea9..3629336 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1745,6 +1745,8 @@ void qemu_system_reset(bool report)
>
> mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
>
> + cpu_synchronize_all_states();
> +
> if (mc && mc->reset) {
> mc->reset();
> } else {
> @@ -1893,7 +1895,6 @@ static bool main_loop_should_exit(void)
> }
> if (qemu_reset_requested()) {
> pause_all_vcpus();
> - cpu_synchronize_all_states();
> qemu_system_reset(VMRESET_REPORT);
> resume_all_vcpus();
> if (!runstate_check(RUN_STATE_RUNNING) &&
> @@ -1903,7 +1904,6 @@ static bool main_loop_should_exit(void)
> }
> if (qemu_wakeup_requested()) {
> pause_all_vcpus();
> - cpu_synchronize_all_states();
> qemu_system_reset(VMRESET_SILENT);
> notifier_list_notify(&wakeup_notifiers, &wakeup_reason);
> wakeup_reason = QEMU_WAKEUP_REASON_NONE;
>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset()
2016-04-04 7:31 ` Paolo Bonzini
@ 2016-04-04 7:54 ` David Gibson
2016-04-04 8:33 ` Paolo Bonzini
0 siblings, 1 reply; 5+ messages in thread
From: David Gibson @ 2016-04-04 7:54 UTC (permalink / raw)
To: Paolo Bonzini
Cc: lvivier, peter.maydell, mtosatti, agraf, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]
On Mon, Apr 04, 2016 at 09:31:16AM +0200, Paolo Bonzini wrote:
>
>
> On 04/04/2016 06:49, David Gibson wrote:
> > There are currently 3 calls to qemu_system_reset() in vl.c. Two of them
> > are immediately preceded by a cpu_synchronize_all_states9) and the
> > remaining one should be.
> >
> > The one which doesn't is the very first reset called directly from main().
> > Without a cpu_synchronize_all_states(), kvm_vcpu_dirty is false at this
> > point from the earlier cpu_synchronize_all_post_init(). That's incorrect
> > because the reset path is quite likely to update the CPU state, and that
> > updated state should be pushed back to KVM, not overwritten with stale
> > data pushed to KVM immediately after init.
> >
> > This patch moves the call to cpu_synchronize_all_states() into
> > qemu_system_reset() for safety, so it is always called. AFAICT this should
> > be safe for the handful of callers outside vl.c - these all appear to be in
> > places where the cpu state is already synchronized so the extra call
> > will be a no-op.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > vl.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > This fixes a real but on ppc - the incorrect state of kvm_vcpu_dirty
> > means that an extra cpu_synchronize_state() in revised code for
> > updating the MSR is not a no-op as expected and loads a stale MSR
> > value, resulting in an incorrect MSR value on entry to the guest.
> >
> > Therefore, I'm hoping to apply this ASAP to 2.6.
> >
> > Laurent, could you please verify that this does indeed address the
> > problem with an incorrect MSR on entry.
> >
> > diff --git a/vl.c b/vl.c
> > index bd81ea9..3629336 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -1745,6 +1745,8 @@ void qemu_system_reset(bool report)
> >
> > mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
> >
> > + cpu_synchronize_all_states();
> > +
> > if (mc && mc->reset) {
> > mc->reset();
> > } else {
> > @@ -1893,7 +1895,6 @@ static bool main_loop_should_exit(void)
> > }
> > if (qemu_reset_requested()) {
> > pause_all_vcpus();
> > - cpu_synchronize_all_states();
> > qemu_system_reset(VMRESET_REPORT);
> > resume_all_vcpus();
> > if (!runstate_check(RUN_STATE_RUNNING) &&
> > @@ -1903,7 +1904,6 @@ static bool main_loop_should_exit(void)
> > }
> > if (qemu_wakeup_requested()) {
> > pause_all_vcpus();
> > - cpu_synchronize_all_states();
> > qemu_system_reset(VMRESET_SILENT);
> > notifier_list_notify(&wakeup_notifiers, &wakeup_reason);
> > wakeup_reason = QEMU_WAKEUP_REASON_NONE;
> >
>
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Thanks Paolo.
Paolo / Peter, should I send this in a pull request for my tree, or
should it go through someone else's tree?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset()
2016-04-04 4:49 [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset() David Gibson
2016-04-04 7:31 ` Paolo Bonzini
@ 2016-04-04 8:24 ` Laurent Vivier
1 sibling, 0 replies; 5+ messages in thread
From: Laurent Vivier @ 2016-04-04 8:24 UTC (permalink / raw)
To: David Gibson, pbonzini, peter.maydell
Cc: mtosatti, qemu-ppc, agraf, qemu-devel
On 04/04/2016 06:49, David Gibson wrote:
> There are currently 3 calls to qemu_system_reset() in vl.c. Two of them
> are immediately preceded by a cpu_synchronize_all_states9) and the
> remaining one should be.
>
> The one which doesn't is the very first reset called directly from main().
> Without a cpu_synchronize_all_states(), kvm_vcpu_dirty is false at this
> point from the earlier cpu_synchronize_all_post_init(). That's incorrect
> because the reset path is quite likely to update the CPU state, and that
> updated state should be pushed back to KVM, not overwritten with stale
> data pushed to KVM immediately after init.
>
> This patch moves the call to cpu_synchronize_all_states() into
> qemu_system_reset() for safety, so it is always called. AFAICT this should
> be safe for the handful of callers outside vl.c - these all appear to be in
> places where the cpu state is already synchronized so the extra call
> will be a no-op.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> vl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> This fixes a real but on ppc - the incorrect state of kvm_vcpu_dirty
> means that an extra cpu_synchronize_state() in revised code for
> updating the MSR is not a no-op as expected and loads a stale MSR
> value, resulting in an incorrect MSR value on entry to the guest.
>
> Therefore, I'm hoping to apply this ASAP to 2.6.
>
> Laurent, could you please verify that this does indeed address the
> problem with an incorrect MSR on entry.
This fixes the unset SF bit of MSR in my test case, so:
Tested-by: Laurent Vivier <lvivier@redhat.com>
Laurent
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset()
2016-04-04 7:54 ` David Gibson
@ 2016-04-04 8:33 ` Paolo Bonzini
0 siblings, 0 replies; 5+ messages in thread
From: Paolo Bonzini @ 2016-04-04 8:33 UTC (permalink / raw)
To: David Gibson
Cc: lvivier, peter.maydell, mtosatti, agraf, qemu-devel, qemu-ppc
On 04/04/2016 09:54, David Gibson wrote:
> > Acked-by: Paolo Bonzini <pbonzini@redhat.com>
>
> Paolo / Peter, should I send this in a pull request for my tree, or
> should it go through someone else's tree?
Go ahead and send it.
Paolo
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-04-04 8:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-04 4:49 [Qemu-devel] [PATCH] vl: Move cpu_synchronize_all_states() into qemu_system_reset() David Gibson
2016-04-04 7:31 ` Paolo Bonzini
2016-04-04 7:54 ` David Gibson
2016-04-04 8:33 ` Paolo Bonzini
2016-04-04 8:24 ` Laurent Vivier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).