It is needed by the hypervisor FreeBSD guest to allocate/free private interrupt vectors.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Admittedly yes. But it does allocate a vector from the IDT range reserved for IPIs. Well, I don't care much about the name, as long as it does what it intend to do.
Should XEN lapic get the same treatment, if even only for the KPI consistency ?
BTW, your baseline source, against which the diff was generated, seems to be old. Diff is still valid, but line numbers are very much off.
XEN overrides the apic_ops, and ipi_alloc is not supported. And I don't have XEN to play with. So I'd leave it to XEN folks.
BTW, your baseline source, against which the diff was generated, seems to be old. Diff is still valid, but line numbers are very much off.
Ah, yeah, its against a local tree, about two weeks old.
I guess one question I should have asked: do you "care" if the IDT vector for hypervisors is in the upper "IPI" region or must it be lower? bhyve apparently wants a vector in the top 16 vectors, but it looks like Xen and Hyper-V have been using a smaller vector prior to that. Is this IDT entry used by the hypervisor to talk to the guest?
If you want a lower vector, then a variant of 'alloc_idt' that worked more like 'alloc_ipi' that accepted a function pointer would also be fine (I'm willing to hack up a prototype in that case).
I don't think we care about it. The code in the current is using a high IDT entry, and we tested the IDT entry ~0x90, which does not make any noticeable difference.
If you want a lower vector, then a variant of 'alloc_idt' that worked more like 'alloc_ipi' that accepted a function pointer would also be fine (I'm willing to hack up a prototype in that case).
I think its fine.
I agree with kib@ that you should just move the #ifdef's in the XEN code to match. Compile testing should be sufficient.