On Thu, Feb 17, 2011 at 07:04:51PM +0100, Jan Kiszka wrote:
> >>> Should not manipulate mp_state of a running vcpu (should only do that
> >>> for migration when vcpu is stopped), since its managed by the kernel,
> >>> for irqchip case.
> >>
> >> Not for asynchronously injected MCEs. The target CPU
On 2011-02-17 18:55, Marcelo Tosatti wrote:
@@ -1375,10 +1413,25 @@ static int kvm_put_vcpu_events(CPUState *env, int
level)
return 0;
}
-events.exception.injected = (env->exception_injected >= 0);
-events.exception.nr = env->exception_inj
On Thu, Feb 17, 2011 at 06:06:19PM +0100, Jan Kiszka wrote:
> On 2011-02-17 17:35, Marcelo Tosatti wrote:
> > On Tue, Feb 15, 2011 at 09:23:32AM +0100, Jan Kiszka wrote:
> >> The current way of injecting MCE events without updating of and
> >> synchronizing with the CPUState is broken and causes sp
On 2011-02-17 17:35, Marcelo Tosatti wrote:
> On Tue, Feb 15, 2011 at 09:23:32AM +0100, Jan Kiszka wrote:
>> The current way of injecting MCE events without updating of and
>> synchronizing with the CPUState is broken and causes spurious
>> corruptions of the MCE-related parts of the CPUState.
>
>
On Tue, Feb 15, 2011 at 09:23:32AM +0100, Jan Kiszka wrote:
> The current way of injecting MCE events without updating of and
> synchronizing with the CPUState is broken and causes spurious
> corruptions of the MCE-related parts of the CPUState.
Can you explain how? The current pronlem with MCE is
The current way of injecting MCE events without updating of and
synchronizing with the CPUState is broken and causes spurious
corruptions of the MCE-related parts of the CPUState.
As a first step towards a fix, enhance the state writeback code with
support for injecting events that are pending in
