On 07/17/2012 06:31 AM, Bhushan Bharat-R65777 wrote:
>>>> int kvm_arch_vcpu_runnable(struct kvm_vcpu *v) {
>>>> - return !(v->arch.shared->msr & MSR_WE) ||
>>>> - !!(v->arch.pending_exceptions) ||
>>>> - v->requests;
>>>> + bool ret = !(v->arch.shared->msr & MSR_WE) ||
>>>> + !!(v->arch.pending_exceptions) ||
>>>> + v->requests;
>>>> +
>>>> + ret = ret || kvmppc_get_tsr_wrc(v);
>>>
>>> Why do you need to declare the cpu as non-runnable when a watchdog
>>> event occured?
>>
>> It's the other way around -- it's always runnable when a watchdog exit is
>> pending. It's like a pending exception.
>
> With the above check, Are we trying to handle the case where watchdog
> interrupt bit in pending_exception is cleared by guest after final
> expiry but before the qemu exit?
No, we're just trying to test the actual condition we want to exit on.
The watchdog interrupt might be masked (either with WIE or CE).
> And we want that if TSR.WRS update
> wins the race with clearing of watchdog interrupt condition from
> guest then anyways let QEMU exit with reason KVM_EXIT_WDT?
What race? If ENW and WIS are both set when the watchdog timer fires,
it's a final expiration. It's irrelevant what happens to WIS after that
point, before enforcement kicks in.
> What if we do not allow guest clear watchdog interrupt condition if
> final expiry already happened?
What would that solve?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
