Re: [Xen-devel] [PATCH v2 2/3] x86/pt: enable binding of GSIs to a PVH Dom0

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Wed, May 17, 2017 at 03:51:43AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 11:34, <roger.pau@xxxxxxxxxx> wrote:
> > On Wed, May 17, 2017 at 03:02:26AM -0600, Jan Beulich wrote:
> >> >>> On 17.05.17 at 10:26, <roger.pau@xxxxxxxxxx> wrote:
> >> > On Tue, May 16, 2017 at 10:23:48AM -0600, Jan Beulich wrote:
> >> >> >>> On 16.05.17 at 17:55, <roger.pau@xxxxxxxxxx> wrote:
> >> >> > On Fri, May 12, 2017 at 07:42:51AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 19.04.17 at 17:11, <roger.pau@xxxxxxxxxx> wrote:
> >> >> >> > Note that currently there's no support for unbinding this 
> >> >> >> > interrupts.
> >> >> >> 
> >> >> >> Do you plan to deal with that before this changes goes in? Aiui this
> >> >> >> not working means you can't pass through devices with pin based
> >> >> >> interrupts once Dom0 chose to bind to them. Otoh hand you modify
> >> >> >> pt_irq_destroy_bind(), so I'm a little puzzled ...
> >> >> > 
> >> >> > Yes, I modify pt_irq_destroy_bind to return EOPNOTSUPP when trying to 
> > unbind
> >> >> > such an interrupt. I can implement the unbind, but it's not going to 
> >> >> > be 
> > used
> >> >> > ATM.
> >> >> 
> >> >> Is it not? I can see the mentioned pass-through case to be of no
> >> >> interest, but wouldn't a well behaved kernel perhaps unmap IRQs
> >> >> while shutting down?
> >> > 
> >> > I guess I haven't explained myself correctly, what I meant is that right 
> > now I
> >> > don't have any use-case for this, I haven't started working on 
> > pci-passtrhough
> >> > for guests, and the Dom0 implementation I have doesn't unbind interrupts 
> >> > on
> >> > shutdown.
> >> > 
> >> > I could unbind them when Dom0 masks the vIO APIC pin, but I think that's
> >> > going to be awfully slow.
> >> 
> >> Well, doesn't this point out another weakness of the no-physdevops
> >> model you advocate for? Implying an unbind from the mask bit being
> >> set in an RTE would certainly be undesirable (there are reasons to
> >> transiently mask an interrupt, after all). Hence there's no way Dom0
> >> could indicate "I'm done with this interrupt", unless I'm missing
> >> something.
> > 
> > The only reason I could see for the hardware domain to unbind an interrupt 
> > is
> > when doing pci-passthrough, and there the toolstack is involved, which could
> > unbind the interrupt using the already existing hypercalls.
> 
> I'm not convinced the tool stack doing this behind the back of the
> kernel is an acceptable thing to do, even more so when thinking
> of shared interrupts.

The toolstack could figure out whether the interrupt is shared or not (edge or
level triggered) and then decide whether it needs unbinding or not. The kernel
must obviously not be using the device by that point. I'm again not opposed to
have an in-kernel (for Dom0) driver for managing passthrough, but I would like
to avoid it if possible.

In any case, I think the interface for how Dom0 interacts with interrupts from
it's assigned devices vs the interface used to detach devices for
pci-passthrough is orthogonal (one can be completely separated from the
other).

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel