Page MenuHomeFreeBSD

x86: Allow interrupt vector allocation/free even on UP
ClosedPublic

Authored by sepherosa_gmail.com on Apr 6 2016, 5:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 23, 10:11 AM
Unknown Object (File)
Dec 20 2023, 1:41 AM
Unknown Object (File)
Nov 15 2023, 1:38 PM
Unknown Object (File)
Nov 13 2023, 12:05 PM
Unknown Object (File)
Nov 10 2023, 7:20 PM
Unknown Object (File)
Nov 9 2023, 1:13 AM
Unknown Object (File)
Nov 8 2023, 2:53 PM
Unknown Object (File)
Nov 7 2023, 8:15 PM
Subscribers
None

Details

Summary

It is needed by the hypervisor FreeBSD guest to allocate/free private interrupt vectors.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

sepherosa_gmail.com retitled this revision from to x86: Allow interrupt vector allocation/free even on UP.
sepherosa_gmail.com updated this object.
sepherosa_gmail.com edited the test plan for this revision. (Show Details)
This revision is now accepted and ready to land.Apr 6 2016, 5:23 AM

the name of IPI sounds strange to me as you are enabling this in UP.

the name of IPI sounds strange to me as you are enabling this in UP.

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.

In D5849#124910, @kib wrote:

Should XEN lapic get the same treatment, if even only for the KPI consistency ?

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.

kib edited edge metadata.
In D5849#124910, @kib wrote:

Should XEN lapic get the same treatment, if even only for the KPI consistency ?

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.

IMO it is enough to compile-test the move of #ifdef SMP there.

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).

In D5849#125035, @jhb wrote:

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?

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.

jhb edited edge metadata.

I agree with kib@ that you should just move the #ifdef's in the XEN code to match. Compile testing should be sufficient.

In D5849#125231, @jhb wrote:

I agree with kib@ that you should just move the #ifdef's in the XEN code to match. Compile testing should be sufficient.

OK.

This revision was automatically updated to reflect the committed changes.