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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
