Re: [PATCH 0/7] Consolidate vcpu ioctl locking

[Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 05/15/2010 11:26 AM, Alexander Graf wrote:
>
>> That means you never inject an interrupt from the iothread (or from a different vcpu thread)?
>>
>> If that's the case we might make it part of the API and require the ioctl to be issued from the vcpu thread.  We'd still be left with the s390 exception.
>>      
> Well I'm not sure that's guaranteed for MOL or Dolphin, but I guess the user base is small enough to ignore them.
>
> Either way, I'm actually rather unhappy with the way interrupts work right now. We're only injecting interrupts when in the main loop, which is rare if we did our homework right. So what I'd really like to see is that the MPIC on ppc directly invokes KVM_INTERRUPT to pull (and losen) the interrupt line. That way we can't just accidently miss interrupts.
>    

on x86 we signal the vcpu thread to pull it out of the main loop and 
poll the apic.

> What happens now with ppc64 guests that have EE lazily disabled is:
>
> * device in userspace wants to trigger an interrupt
> * mpic pulls external interrupt line
>    

<signal>

> * kvm_arch_pre_run sees that external interrupt line is pulled, issues ioctl(KVM_INTERRUPT), kernel space sets trigger_interrupt=1
> * we enter the guest
> * we inject an external interrupt, set trigger_interrupt=0
> * guest gets the interrupt, sees it's lazily disabled, sets msr.ee=0
> * guest moves on, sets msr.ee=1 again later
> *** guest expects the interrupt to trigger again, but we don't know that it's still pending
>    

Why does the guest expect the interrupt to trigger again?  Is it level 
triggered until acknowledged?

That's exactly why x86 has run->request_interrupt_window, 
run->ready_for_interrupt_injection, and run->if_flag.

> ->  we need to exit to userspace to realize that the interrupt is still active
>
> This is fundamentally broken. What I'd like to see is:
>
> * device in userspace wants to trigger an interrupt
> * mpic pulls external interrupt line, automatically issues ioctl(KVM_INTERRUPT)
> * we enter the guest
> * we inject the external interrupt
> * guest gets the interrupt, sees it's lazily disabled, sets msr.ee=0
> * guest moves on, sets msr.ee=1 again later
> * we inject the external interrupt again, since it's still active
> * guest acknowledges the interrupt with the mpic, issues ioctl(KVM_INTERRUPT, disable)
> ->  all is great
>    

This is similar to KVM_IRQ_LINE.

> For that to work we need to enable triggering KVM_INTERRUPT from a non-vcpu thread.
>    

KVM_IRQ_LINE is a vm ioctl instead of a vcpu ioctl.

The motivation for the strict 'issue vcpu ioctls from vcpu thread' rule 
is to prepare the way for a syscall (instead of ioctl) API.  Then we 
lost the fd argument, and choosing the vcpu is done by associating it 
with the current task.  That allows us to get rid of vcpu->mutex and 
fget_light() (as well as the ioctl dispatch).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.