Re: Any standard kernel API to dynamically allocate/free per-cpu vectors on x86?

[Thomas Gleixner]

Dexuan,

On Wed, 4 Apr 2018, Dexuan Cui wrote:

> Hi,
> Recently, two Hyper-V specific vectors were introduced in
> arch/x86/include/asm/irq_vectors.h:
> 
> #if IS_ENABLED(CONFIG_HYPERV)
> #define HYPERV_REENLIGHTENMENT_VECTOR   0xee
> #define HYPERV_STIMER0_VECTOR           0xed
> #endif
> 
> What if we need more such vectors on Hyper-V? This static global reservation
> mechanism doesn't scale, IMO.
> 
> Actually I believe we don't really need to reserve the same vector on all CPUs,
> because the model-specific registers (MSRs) defined for Hyper-V synthetic 
> interrupt controller (SynIC) are per-cpu, meaning each virtual processor has
> its own copy of these registers, so they can be programmed independently.
> 
> That is to say, we can use different vectors for the same Synthetic Interrupt,
> as long as we're able to dynamically get a per-cpu vector for each CPU.
> 
> I'm wondering if there is such a standard kernel API on x86. 
> As I skimmed through the code, I haven't found it yet, if any.
> 
> PS, the background of my question is that: in the future Hyper-V will
> support multiple VMBus drivers running simultaneously in one virtual
> machine, and I think it would be better for the future secondary VMBus
> driver to use a different synthetic interrupt, which I hope can be
> configured with dynamic vectors rather than a new static globally-reserved
> vector.

We don't have a simple way to do such allocations because they involve IDT
entry manipulation.

If there is no hard requirement that this stuff runs through an direct
vector, then we could simply make these interrupts go through the normal
interrupt path. That means you have to request them like regular device
interrupts and the handling path is slightly longer than the direct vector
mode. You'd get virtual interrupt numbers per cpu which also show up in
/proc/interrupts as separate lines.

That needs a very simple and minimal virtual interrupt controller driver
which is mostly a dummy implementation except for the activation function
which would allow you to retrieve the vector number and store it in the
MSR.

There are a few details to be hashed out vs. CPU hotplug, but we have all
the infrastructure in place to deal with that.

Hmm?

Thanks,

	tglx