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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Oct 2009 15:27:50 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <gregory.haskins@...il.com>
CC:	Gregory Haskins <ghaskins@...ell.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	alacrityvm-devel@...ts.sourceforge.net
Subject: Re: [Alacrityvm-devel] [KVM PATCH v2 1/2] KVM: export lockless GSI
 attribute

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/