On 2016-06-26 03:48, Peter Xu wrote: > On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote: >> On 2016-06-25 15:18, Peter Xu wrote: >>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote: > > [...] > >>> I have a thought on how to implement the "sink" you have mentioned: >>> >>> First of all, in KVM, we provide a new KVM_IRQ_ROUTING_* type, maybe >>> called: >>> >>> KVM_IRQ_ROUTING_EVENTFD >> >> Not really, because all sources are either using eventfds, which you can >> also terminate in user space (already done for vhost and vfio in certain >> scenarios - IIRC) or originate there anyway (IOAPIC). > > But how should we handle the cases when the interrupt path are all in > kernel?
There are none which we can't redirect (only full in-kernel irqchip would have, but that's unsupported anyway). > > For vhost, data should be transfered all inside kernel when split > irqchip and irqfd are used: when vhost got data, it triggers irqfd to > deliver the interrupt to KVM. Along the way, we should all in kernel. > > For vfio, we have vfio_msihandler() who handles the hardware IRQ and > then triggers irqfd as well to KVM. Again, it seems all in kernel > space, no chance to stop that as well. > > Please correct me if I was wrong. Look at what vhost is doing e.g.: when a virtqueue is masked, it installs an event notifier that records incoming events in a pending state field. When it's unmasked, the corresponding KVM irqfd is installed. Jan
signature.asc
Description: OpenPGP digital signature
