[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |