On 04/05/2017 14:06, Andrew Jones wrote:
>>> +VCPU threads may need to consider requests before and/or after calling
>>> +functions that may put them to sleep, e.g. kvm_vcpu_block(). Whether they
>>> +do or not, and, if they do, which requests need consideration, is
>>> +architecture dependent. kvm_vcpu_block() calls kvm_arch_vcpu_runnable()
>>> +to check if it should awaken. One reason to do so is to provide
>>> +architectures a function where requests may be checked if necessary.
>> What did you have in mind here?
> I was trying to point out vcpu request concerns with respect to sleeping
> vcpus, but to stay as general as possible. I can't really think of
> anything else to say here, other than to give some hypothetical example.
> For a while I was thinking I might check requests (kvm_request_pending())
> from the kvm_arch_vcpu_runnable() call for ARM, but then changed my mind
> on that - leaving it only checking the pause and power_off booleans.
> Anyway, I don't think the above paragraph is "wrong", but if it's
> confusing then I can change / remove it as people like. Just let me know
> how you'd like it changed :-)
I think the x86 scheme, where you only process requests once you have
decided you'll get IN_GUEST_MODE, is a good one.
That is, they _may_ check some requests in kvm_arch_vcpu_runnable but
not process them.
For ARM this would be:
if (vcpu->arch.power_off || vcpu->arch.pause) {
vcpu_sleep(vcpu);
ret = 0;
} else {
ret = vcpu_enter_guest(vcpu);
}
where vcpu_enter_guest is basically the "while (ret > 0)" loop in
kvm_arch_vcpu_ioctl_run:
/*
* Check conditions before entering the guest
*/
cond_resched();
update_vttbr(vcpu->kvm);
preempt_disable();
...
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
vcpu->arch.power_off || vcpu->arch.pause) {
local_irq_enable();
kvm_pmu_sync_hwstate(vcpu);
kvm_timer_sync_hwstate(vcpu);
kvm_vgic_sync_hwstate(vcpu);
preempt_enable();
return ret;
}
...
preempt_enable();
return handle_exit(vcpu, run, ret);
In your case, you don't need to check any request in
kvm_arch_vcpu_runnable, I think. This split would also solve my review
doubt from "Re: [PATCH v3 05/10] KVM: arm/arm64: don't clear exit
request from caller".
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
