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? 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. [...] > > - there are works that depend on this series, so I would appreciate if > > this series can be merged first, so that other people can have a > > good basement (Radim's x2apic, David's AMD IOMMU). Though this is > > based on the assumption that the basic design of this series is > > workable... > > I understand, and it is probably safe... > > > > > - this problem will only exist for guest driver developers and should > > not happen for generic users (right?), so only a small subset of > > users might be affected. > > ...provided there is only little risk that some guest programs some > half-backed or stale message that would be rejected prematurely. But > that risk is most likely low. Yes, thanks! -- peterx
