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

[Wei Liu]

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.