On 27.09.2011, at 02:44, Scott Wood wrote:
> On 09/24/2011 02:27 AM, Alexander Graf wrote:
>> I think I'm getting your point. So what we want is:
>>
>> in timer handler:
>>
>> set_bit(TSR_DIS, vcpu->arch.tsr);
>> kvm_make_request(KVM_REQ_PPC_TSR_UPDATE, vcpu);
>> kvm_vcpu_kick(vcpu);
>>
>> in vcpu entry code:
>>
>> if (vcpu->requests)
>> if (kvm_check_request(KVM_REQ_PPC_TSR_UPDATE, vcpu))
>> kvmppc_update_tsr(vcpu);
>>
>> void kvmppc_update_tsr(struct kvm_vcpu *vcpu)
>> {
>> if (vcpu->arch.tsr & TSR_DIS &&
>> vcpu->arch.tcr & TCR_DIE) {
>> kvmppc_core_queue_dec(vcpu);
>> }
>> // XXX also implement dequeue!
>> }
>
> OK, this avoids the possibility for the guest to clear DIS/DIE after
> enqueue but before delivery (which in the current patch is dealt with by
> an extra check at delivery), and we only have to check one thing in the
> common nothing-requested case (even if more things use this mechanism,
> as long as we don't run out of bits).
>
> If we convert external IRQs to using this as well, and expand the timer
> case to include non-booke (maybe just use KVM_REQ_PENDING_TIMER?), we
> should be able to de-atomicize pending_exceptions (which should be a
> bigger win than de-atomicizing arch.tsr).
>
>> case SPR_TSR:
>> vcpu->arch.tsr &= ~TSR_DIS;
>> kvmppc_update_tsr(vcpu);
>
> Well, we should probably replace TSR_DIS here with the actual value that
> the guest wrote. :-)
Yes, and use the atomic operation. This is all just pseudo-code.
I like the idea of moving pending_exceptions off of atomic. This really is a private field that no other vcpu should have access to. We only have to think hard about how to implement SET_INTERRUPT for another vcpu then. But I think this could just be another kvm_make_request() type.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
