Re: [PATCH 4/9] KVM: Adds ability to preemptanexecutingVCPU

Dor Laor
2007-05-10T13:03:21Z

>
>>>>>+ }
>>>>
>>>>
>>>> A possible optimization would be to check if we have an irq to
>> inject.
>>>> If we have, then ignore the signal and enter guest mode.
>>>> Since an irq is already pending, the signal would not be resulting
in
>>>> another irq injection.
>>>> What do you think?
>>>
>>>I am a little fuzzy on whether this is necessary myself. The
>> motivation
>>>for this code block originally was really more for the cases where
>> signals
>>>are sent that *aren't* related to interrupts. For instance, what if
>> QEMU
>>>was trying to force the vCPU to exit for some reason (e.g. an AIO
>>>completion event that has to be decoded by userspace before a IRQ is
>>>generated)? If the signal is queued beforehand AND linux doesn't
>> already
>>>reschedule things for us, I think there is a race against the VCPU
>> being
>>>stuck in guest mode until the next (unrelated) VMEXIT since the IPI
>> would
>>>have already happened. This code (I believe) closes the window on
that
>>>scenario. I am just not sure if its a realistic one. Perhaps
someone
>> with
>>>more linux signal handling knowledge than myself can chime in and
>> confirm?
>>>(And I am not saying that person isn't you, Dor. I am only saying it
>> isn't
>>>me ;)
>>
>>
>> You're right that there is a slight chance for a qemu signal such as
AIO
>> completion to reach right after we enter the kernel. My intention was
to
>> unit the signal pending checks - there is another one after the
guest
>> exits vmx mode. Then once we're back on host mode we can optimize the
>> path by checking whether we need to re- inject in- kernel- apic
pending
>irq
>> or a case where a physical irq prevented us from injecting the virq.
>>
>> The optimization is not specific to apic and can take place even now.
>
>I'm not entirely following you, but you if elaborate a little more
perhaps
>I can get it incorporated. Otherwise, we could just wait till this
logic
>is merged and do a follow on patch.
>

I was thinking of optimize cases where the guest exits vmx mode but has
virq to inject. In that point a signal might be pending.
The current code exits to userspace although userspace would not be able
to inject another irq before the pending one will be injected.
Instead, don't exit to userspace and inject the pending irq.

I'm not sure it will make a big different.

At least collapsing the two places we check for signal is good.