On Mon, Dec 12, 2011 at 12:44 PM, Avi Kivity <a...@redhat.com> wrote:
> On 12/12/2011 06:20 PM, Christoffer Dall wrote:
>> >>
>> >> +/**
>> >> + * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by
>> >> a guest
>> >> + * @vcpu: the vcpu pointer
>> >> + * @run: the kvm_run structure pointer
>> >> + *
>> >> + * Simply sets the wait_for_interrupts flag on the vcpu structure, which
>> >> will
>> >> + * halt execution of world-switches and schedule other host processes
>> >> until
>> >> + * there is an incoming IRQ or FIQ to the VM.
>> >> + */
>> >> int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> >> {
>> >> + trace_kvm_wfi(vcpu->arch.regs.pc);
>> >> + if (!vcpu->arch.virt_irq)
>> >> + vcpu->arch.wait_for_interrupts = 1;
>> >
>> > Why not just block here?
>> >
>>
>> well, if we block, but receive a signal that we want to go back into
>> userspace for, and then come back but the guest should still be
>> waiting, then I want that flag set, and I think it's the most logical
>> control flow. Am I missing something completely?
>
> That's just not the flow that the other archs use, I don't think that it
> really matters. kvm_vcpu_block() checks for and wakes up on signals, so
> it's okay to call it from here directly.
>
yes, but I still have to perform the check again in the main run
function if it woke up for anything else than a guest interrupt, so
why call it twice...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
