[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 12/24] xen/arm: Release IRQ routed to a domain when it's destroying



Hi Ian,

On 23/02/15 15:25, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:41 +0000, Julien Grall wrote:
> 
>>>> +    /* TODO: Handle eviction from LRs. For now, deny remove if the IRQ
>>>> +     * is inflight and not disabled.
>>>
>>> If we are ungracefully killing a guest doesn't this risk ending up with
>>> an undestroyable domain? i.e. if the guest is paused with an inflight
>>> IRQ and then destroyed, how does the inflight IRQ ever become
>>> not-inflight again? A similar argument could apply if the guest has e.g.
>>> crashed, paniced or is otherwise not processing any more interrupts or
>>> generating EOIs for existing ones.
>>
>> No, this will fall on the "is_dying" part. During domain destruction,
>> the hypervisor will release all the IRQ still assigned to the guest one
>> by one.
>>
>>> We need to be able to kill a guest in such a state somehow.
>>
>> The TODO is here for running domain where we try to deassign an inflight
>> IRQ.
> 
> I see. I think either expand the comment to say "for a running domain"
> or, probably better, put this bit of code (and the comment) in an else
> of the is_dying and get rid of the goto in the is_dying==true case.

I will do.

>>>> +    for ( i = 0; i < (d->arch.vgic.nr_spis); i++ )
>>>> +    {
>>>> +        struct pending_irq *p = &d->arch.vgic.pending_irqs[i];
>>>
>>> Is there not a helper for this lookup? If so it should be used.
>>
>> The irq_pending code is adding extra-check. But I guess we don't care
>> for domain destruction?
> 
> I don't think so.

Ok.

Regards,

-- 
Julien Grall

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.