Re: [PATCH v2 17/17] x86/hyperv: handle IO-APIC when running as root

From: Wei Liu
Date: Fri Nov 13 2020 - 11:05:09 EST


On Fri, Nov 13, 2020 at 04:01:58PM +0000, Wei Liu wrote:
> On Thu, Nov 12, 2020 at 05:56:41PM +0100, Vitaly Kuznetsov wrote:
> [...]
> > > +static unsigned int hv_ioapic_startup_irq(struct irq_data *data)
> > > +{
> > > + u16 status;
> > > + struct IO_APIC_route_entry ire;
> > > + u32 vector;
> > > + struct irq_cfg *cfg;
> > > + int ioapic;
> > > + u8 ioapic_pin;
> > > + int ioapic_id;
> > > + int gsi;
> > > + union entry_union eu;
> > > + struct cpumask *affinity;
> > > + int cpu, vcpu;
> > > + struct hv_interrupt_entry entry;
> > > + struct mp_chip_data *mp_data = data->chip_data;
> > > +
> > > + gsi = data->irq;
> > > + cfg = irqd_cfg(data);
> > > + affinity = irq_data_get_effective_affinity_mask(data);
> > > + cpu = cpumask_first_and(affinity, cpu_online_mask);
> > > + vcpu = hv_cpu_number_to_vp_number(cpu);
> > > +
> > > + vector = cfg->vector;
> > > +
> > > + ioapic = mp_find_ioapic(gsi);
> > > + ioapic_pin = mp_find_ioapic_pin(ioapic, gsi);
> > > + ioapic_id = mpc_ioapic_id(ioapic);
> > > + ire = ioapic_read_entry(ioapic, ioapic_pin);
> > > +
> > > + /*
> > > + * Always try unmapping. We do not have visibility into which whether
> > > + * an IO-APIC has been mapped or not. We can't use chip_data because it
> > > + * already points to mp_data.
> > > + *
> > > + * We don't use retarget interrupt hypercalls here because Hyper-V
> > > + * doens't allow root to change the vector or specify VPs outside of
> > > + * the set that is initially used during mapping.
> > > + */
> > > + status = hv_unmap_ioapic_interrupt(gsi);
> > > +
> > > + if (!(status == HV_STATUS_SUCCESS || status == HV_STATUS_INVALID_PARAMETER)) {
> > > + pr_debug("%s: unexpected unmap status %d\n", __func__, status);
> > > + return -1;
> >
> > Nit: the function returns 'unsigned int' but I see other 'irq_startup'
> > routines return negative values too, however, they tend to returd
> > '-ESOMETHING' so maybe -EFAULT here?
> >
>
> The return type should've been int instead. That's what the function
> signature in struct irq_chip looks like.

Actually it is unsigned int. Oh well.

Wei.