qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v10 16/26] intel_iommu: add support for split ir


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v10 16/26] intel_iommu: add support for split irqchip
Date: Sun, 26 Jun 2016 09:48:47 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]