Re: [RFC PATCH 1/2] kvm: x86: add new gsi route type EVENTFD

[Peter Xu <peterx@redhat.com>]

On Wed, Feb 08, 2017 at 09:26:10AM +0100, Paolo Bonzini wrote:
> 
> 
> On 08/02/2017 08:58, Peter Xu wrote:
> > This idea was invoked when I was trying to solve an emulated VT-d issue
> > when guest kernel setup incorrect IRTE. When that happens, instead of
> > raising error immediately, what we should do is to keep the error, and
> > inject this error to vIOMMU when the specific interrupt is triggered.
> > 
> > However this is very hard to be achieved since for now vIOMMU is working
> > in userspace, while currently there is no simple way that kernel irq can
> > talk to a userspace program.
> > 
> > With this patch, we can easily provide such a way that when guest fault
> > irq is triggered, kernel can notify user program by signaling the
> > corresponding eventfd handle
> 
> I think I understand the scenario, but I don't understand why it needs
> kernel intervention.  Why couldn't this be handled entirely in
> userspace, without ever setting up a GSI route or irqfd in KVM?  In
> other words, you're doing
> 
>  write(irqfd)         read(irq fault eventfd)
>        |                       ^
>        v                       |
>       KVM -------> KVM_GSI_ROUTING_EVENTFD
> 
> but why is this needed as opposed to just
> 
>  write(irqfd) ------> read(irq fault eventfd)
> 
> ?

Paolo,

Thanks for pointing out this issue. This is one of my concern as well,
and Jan has had the same comment before (sorry I forgot to cc Jan,
doing it now). I was trying to identify the risk for both solutions. I
posted this just trying to choose one way out of the two, and
currently this series is my clumsy choice.

I agree that logicall this can be done all in userspace. Now the
problem is that, I am afraid we can't do it easily, and lots of codes
may need to be touched for QEMU to achieve a whole userspace solution
- now we not only need irqfd and virq to setup a route, we need to
prepare a fault sink for each of the irqfd. Not to say that we have
lots of assumption in QEMU that virq and irqfd are treated seperately.
That'll of course expand the test scope as well, covering all the
devices using irqfd. Of course we can try to abstract that out into
something common, I am just afraid that'll be still a relatively big
change, and I am still uncertain about the "size" of it.

With this feature, everything will be in control totally in vIOMMU
side in QEMU. It'll be fairly straightforward and clean. But of course
I understand your concern since we should keep KVM as simple as
possible, even this is only tens of lines of changes (I wouldn't dare
to post a series for this for more than 100 LOCs :-).

And, even if we don't like this feature bit, I am still not sure
whether I should move on on QEMU side to do a possible big change only
to benefit error handling in VT-d vIOMMU. Any of your further comment
would be welcomed to help me settle this down.

(Or, maybe I should just put this problem aside for now. Comparing to
 solve this, I think fixing the IRTE bug in kernel might be easier :-)

Thanks,

-- peterx