Avi Kivity wrote: > Gregory Haskins wrote: >> Avi, >> >> Gregory Haskins wrote: >> >>> Todo: >>> *) Develop some kind of hypercall registration mechanism for KVM so >>> that >>> we can use that as an integration point instead of directly hooking >>> kvm hypercalls >>> >> >> What would you like to see here? I now remember why I removed the >> original patch I had for registration...it requires some kind of >> discovery mechanism on its own. Note that this is hard, but I figured >> it would make the overall series simpler if I didn't go this route and >> instead just integrated with a statically allocated vector. That being >> said, I have no problem adding this back in but figure we should discuss >> the approach so I don't go down a rat-hole ;) >> >> > > > One idea is similar to signalfd() or eventfd(). Provide a kvm ioctl > that takes a gsi and returns an fd. Writes to the fd change the state > of the line, possible triggering an interrupt. Another ioctl takes a > hypercall number or pio port as well as an existing fd. Invocations > of the hypercall or writes to the port write to the fd (using the same > protocol as eventfd), so the other end can respond. > > The nice thing is that this can be used by both kernel and userspace > components, and for kernel components, hypercalls can be either > buffered or unbuffered. And thus the "kvm-eventfd" (irqfd/iosignalfd) interface project was born. ;) (Michael FYI: so I will be pushing a vbus-v4 series at some point in the near future that is expressed in terms of irqfd/iosignalfd, per the conversation above. The patches in v3 and earlier are more intrusive to the KVM core than they will be in final form) -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
