On 05/16/2010 04:00 AM, Alexander Graf wrote:
On 15.05.2010, at 19:30, Avi Kivity wrote:
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.
Hrm, makes sense. Though it's additional overhead of a task switch. Why take
the burden if you don't have to?
That's what the world looked like in 2006.
We could change it, but there's not much point, since having the local
apic in the kernel is pretty much a requirement for reasonable performance.
That's exactly why x86 has run->request_interrupt_window,
run->ready_for_interrupt_injection, and run->if_flag.
So how does x86 userspace get notified when it has an interrupt pending but
couldn't inject it? Without a notification, we delay interrupts by quite some
time.
run->ready_for_interrupt_injection and run->request_irq_window.
-> 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.
Well, KVM_IRQ_LINE would be the in-kernel pic, no? That'd mean I'd have to
reimplement the mpic in kernel space - which might eventually be a good idea
when going for SMP, but I'd first like to see if I can keep the current
interrupt injection path efficient.
Sure.
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).
If we define the API to only work on the current vcpu with a few excetions
where we're safe (KVM_INTERRUPT), that'd get rid of the mutex too, no?
Yes. Need to document it though.
What does fget_light do?
Make sure that the vcpu fd doesn't disappear.
And does the ioctl dispatch cost that much? I like the flexibility of it to be
honest.
Not much, which is why there's no movement in that direction.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
