[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 2/2] x86/IRQ: allocate guest array of max size only for shareable IRQs
On 03.12.2020 02:58, Igor Druzhinin wrote: > @@ -1540,6 +1540,7 @@ int pirq_guest_bind(struct vcpu *v, struct pirq *pirq, > int will_share) > unsigned int irq; > struct irq_desc *desc; > irq_guest_action_t *action, *newaction = NULL; > + unsigned int max_nr_guests = will_share ? irq_max_guests : 1; > int rc = 0; > > WARN_ON(!spin_is_locked(&v->domain->event_lock)); > @@ -1571,7 +1572,7 @@ int pirq_guest_bind(struct vcpu *v, struct pirq *pirq, > int will_share) > { > spin_unlock_irq(&desc->lock); > if ( (newaction = xmalloc_bytes(sizeof(irq_guest_action_t) + > - irq_max_guests * sizeof(action->guest[0]))) != NULL && > + max_nr_guests * sizeof(action->guest[0]))) != NULL && > zalloc_cpumask_var(&newaction->cpu_eoi_map) ) > goto retry; > xfree(newaction); > @@ -1640,7 +1641,7 @@ int pirq_guest_bind(struct vcpu *v, struct pirq *pirq, > int will_share) > goto retry; > } > > - if ( action->nr_guests == irq_max_guests ) > + if ( action->nr_guests == max_nr_guests ) > { > printk(XENLOG_G_INFO "Cannot bind IRQ%d to dom%d. " > "Already at max share %u, increase with irq_max_guests= > option.\n", Just as a minor remark - I don't think this last hunk is necessary, as the !will_share case won't make it here unless action->nr_guests is still zero. At which point the need for the new local variable would also disappear. But I'm not going to insist, as there may be the view that the code is more clear this way. However, if clarity (in the sense of "obviously correct") is the goal, then I think using >= instead of == would now become preferable. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |