Re: [Alacrityvm-devel] [KVM PATCH v2 1/2] KVM: export lockless GSI attribute

[Avi Kivity <avi@redhat.com>]

On 10/28/2009 03:19 PM, Gregory Haskins wrote:
>> Yes, and it also contains the work_struct.
>>
>> What if we make the work_struct (and any additional state) part of the
>> set_atomic() argument list?  Does it simplify things?
>>      
> Hmmm, that might not, but we could do a kmalloc(GFP_ATOMIC) for such
> parameters.  Considering this is just a safety net, perhaps this would
> work fine.
>    

Can't you simply pass the same work_struct from irqfd as we use now?

>>> So while generalizing this perhaps makes sense at some point, especially
>>> if irqfd-like interfaces get added, it probably doesn't make a ton of
>>> sense to expend energy on it ATM.  It is basically a generalization of
>>> the irqfd deferrment code.  Lets just wait until we have a user beyond
>>> irqfd for now.  Sound acceptable?
>>>
>>>        
>> I'll look at v3, but would really like to disentangle this.
>>      
> Ok, I will see what I can do.  I need at least a v4 to get rid of the
> dependency on the now defunct v3:1/3 patch per yesterdays discussion.
>    

There's another alternative - make ioapic and pic irq-safe by switching 
irq locking to spinlocks and using spin_lock_irqsave().

I've long opposed this since the ioapic loops on all vcpus when 
injecting some irqs and this will increase irqoff times with large 
guests.  But we don't have large guests now, and we need irq-safe 
injection in three places now:

- irqfd
- pit - we now signal vcpu0 to handle the injection, but this has its 
problems
- device assignment

so it may be better to have irq-safe injection, and deal with the loop 
later (would be good to have an idea how exactly).

-- 
error compiling committee.c: too many arguments to function