On 08/26/2009 01:29 PM, Michael S. Tsirkin wrote:
How we wanted to solve it with EFD_STATE: Share a separate eventfd
between each device and the hypervisor. device sets state to either 0
or 1. hypervisor polls all eventfds, reads interrupt line on changes,
calculates the interrupt level and updates guest.
Alternative solution: shared memory where each device writes interrupt
line value. This makes setup more complex (need to share around much more
than just an fd), and makes access from interrupt impossible unless we
lock the memory (and locking userspace memory introduces yet another set
of issues).
For completeness:
If the device is implemented in the same process as the hypervisor, an
eventfd isn't really needed, as there is an ioctl which performs the
same operation.
An important class of device implementations is real devices that are
assigned to a guest. We would like to forward the interrupt directly
from the host interrupt handler to qemu. Currently, we have a
kvm-specific interrupt handler that forwards the interrupt using
kvm-specific interfaces. We would like to use a generic interrupt
handler implemented by uio, so we want a generic interrupt transfer
mechanism.
uio already supports edge-triggered interrupts using an eventfd-like
mechanism. So it makes sense to extend uio to support real eventfds,
and to make it also support level-triggered interrupts.
We can work around the lack of state eventfd by having userspace wait on
whatever mechanism uio uses to make the interrupt state visible, and
then use the ioctl mentioned above to inform the hypervisor of this
state. But it's faster and nicer to give both components an eventfd and
let them communicate directly.
--
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
