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

Jan


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