Page MenuHomeFreeBSD

specific end of interrupt implementation for AMD Local APIC
AbandonedPublic

Authored by avg on Mar 3 2017, 11:32 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 20, 8:30 PM
Unknown Object (File)
Wed, Nov 13, 10:04 AM
Unknown Object (File)
Fri, Nov 1, 2:57 AM
Unknown Object (File)
Sat, Oct 26, 4:22 PM
Unknown Object (File)
Fri, Oct 25, 9:44 PM
Unknown Object (File)
Thu, Oct 24, 10:20 PM
Unknown Object (File)
Oct 21 2024, 12:20 AM
Unknown Object (File)
Oct 20 2024, 9:20 AM
Subscribers

Details

Summary

The change is more intrusive than I would like because the feature
requires that a vector number is written to a special register.
Thus, now the vector number has to be provided to lapic_eoi().
It was readily available in the IO-APIC and MSI cases, but the IPI
handlers required more work.
Also, we now store the VMM IPI number in a global variable, so that it
is available to the justreturn handler for the same reasons.

Test Plan

Tested on my 10h machine with both i386 and amd64 kernels.
Also, I tested bhyve/vmm with the amd64 kernel.
All devices worked as before, no anomalities were seen.
Some devices uses MSIs, some IO-APIC interrupts.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 7895
Build 8035: arc lint + arc unit

Event Timeline

avg retitled this revision from to specific end of interrupt implementation for AMD Local APIC.
avg updated this object.
avg edited the test plan for this revision. (Show Details)
avg added reviewers: grehan, jhb, kib, neel, royger.
sys/i386/i386/apic_vector.s
203

What is this ? AMD64 ABI passes arg0 in %edi.

sys/x86/x86/local_apic.c
453

You moved the functions around, but old location contains a better variant of amd_read_ext_features(), at least.

1042

I suggest to define two symbolic constants e.g. EOIS_INTEL and EOIS_AMD, and assign it to lapic_eoi_suppression. Then you would only need to compare lapic_eoi_suppression with the constant (one check), instead of verifying that the var is not zero and check vendor (two checks).

sys/i386/i386/apic_vector.s
203

This is i386 file.

sys/x86/x86/local_apic.c
453

Oh! Thank you for noticing.
This is what I got because of jumping back and forth between git, svn and phabricator.

1042

This sounds like a good suggestion. One concern is how to keep things simple for the tunable.
I'll think about that.

sys/x86/x86/local_apic.c
1042

You only need to distinguish between zero and non-zero for tunable; any non-zero value should be adjusted into the vendor constant.

address comment form kib:

  • restore better version of amd_read_ext_features
  • use different values of lapic_eoi_suppression to distinguish Intel and AMD SEOI implementations
avg marked 7 inline comments as done.Mar 4 2017, 2:48 PM
sys/amd64/amd64/apic_vector.S
312

All this comment is outdated.

318

It would be much less wordy to define the vmm_ipinum in C and only reference the symbol in asm.

sys/amd64/vmm/vmm.c
218

I.e. just remove static there.

sys/x86/x86/local_apic.c
462

'else' is not needed, -1 line.

491

Merge all int vars declarations into single line.

sys/amd64/amd64/apic_vector.S
318

I agree, but what would be a good place to do it? (see my other comment)

sys/amd64/vmm/vmm.c
218

vmm can be compiled as a modules (in fact, I am not sure if it can be compiled into the kernel).
In that case, I think, we would get a linker error.

avg marked an inline comment as done.

address comments

sys/amd64/vmm/vmm.c
218

I do not see a problem with #ifdef amd64 around a define in local_apic.c.

kib edited edge metadata.
This revision is now accepted and ready to land.Mar 5 2017, 5:26 PM
This revision was automatically updated to reflect the committed changes.

The commit was reverted.

This revision is now accepted and ready to land.Mar 27 2017, 12:35 PM

It seems that the Specific EOI feature (along with LAPIC side interrupt masking) is only useful for assigning hardware interrupts to virtual machines.
It does not provide performance benefits similar to Intel EOI Suppression feature.
So, Specific EOI could still be useful, but given the amount of code change and no immediate use for it, I am closing this request now.
We can reconsider the code later if we see that we need it.