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: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.

Just to be clear, my no-physdevops thing is about how guests interact with
physical devices when using them in a native way. Things like pci-passthrough
(that are not part of how an OS operates) should indeed use hypercalls (because
there's no native way to do this).

Roger.

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