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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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