Re: SV: apic i kernen ?

From: Poul-Henning Kamp (none@phk--phk.freebsd.dk.lh.bsd-dk.dk)
Date: Mon 13 Feb 2006 - 11:17:48 CET


To: bsd-dk@bsd-dk.dk
Subject: Re: SV: apic i kernen ? 
From: "Poul-Henning Kamp" <none@phk--phk.freebsd.dk.lh.bsd-dk.dk>
Date: Mon, 13 Feb 2006 10:17:48 +0000

In message <none@20060213094156.14450.qmail--web26801.mail.ukl.yahoo.com.lh.bsd-dk.dk>, Claus Gutt
esen writes:
>> Nogen der kan forklare mig hvad 'apic' egentlig er
>
>Bruges bl.a. til at starte evt. andre cpu'er i
>systemet.

Mnjae, men det er nu en utroligt lille del af historien...

APIC er de moderne interrupt controller(e), i modsætning til i8259
chippen (som stadig emuleres).

Fordi interrupt routing i multi-cpu systemer nødvendigvis må vide
at der er flere CPU'er, anvendes APIC også til at sende signaler
fra en CPU til en anden ("IPI").

MPBIOS specifikationen definerer hvordan operativsystemer finder
ud af CPU topologien og hvilke IPI'er man skal sende for at få
andre cpu'er end "boot cpu'en" i sving.

Derfra kommer den lille del som Claus anfører.

For nu at gøre det lidt vanskeligt, så består APIC af flere stumper
rundt omkring på MOBO.

Hver CPU har mindst en APIC, multicore chips har en APIC per core
dog ikke nødvendigvis hvis det er fup-multicore som HTT.

Derudover findes der en eller flere IO-APIC som er funktionsblokke
der har fat i I/O enhedernes interrupt request linier og oversætter
disses signaler til interrupt requests på en eller flere CPU'er
afhængigt af hvordan man har konfigureret tingene.

De forskellige APIC's står i indbyrdes forbindelse, enten via en
dedikeret "APIC-BUS" eller ved at stjæle cycles på hoved bus(serne).

Endelig er der nu kommet en ny slags interrupt, der ikke sendes
via separate ledninger (#A, #B, #C & #D) i PCI bussen, men som
"messages" på hovedbussen (== hurtigere, mindre hardware, flere
interrupt vektorer per device). Igen er det APIC-sammensværgelsen
der har jobbet med at holde styr på sagen.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:57 CET