Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
On Thu, 8 Feb 2001, Mikael Pettersson wrote: > No, poking into MSRs not explicitly defined on the current CPU is > inherently unsafe. I have several x86 CPU data sheets here in front > of me which say the same thing: "Don't write to undocumented MSRs." Your point is right -- the problem are not undefined MSRs (that raise #GP(0) on an access) but undocumented ones, sigh... > You cannot assume that every single x86 out there stays clear of > all Intel-defined MSRs. Intel has also expanded this set over time: > older designs may not even have known about the APIC_BASE MSR. Intel is actually sane -- you get #GP(0) for this MSR on P5. Others might not and there are less cluefull vendors out there. > 1. identify_cpu() (and more importantly get_cpu_vendor()) is called [...] > 2. include/asm-i386/processor.h #defines X86_VENDOR_INTEL as 0. [...] > 3. init/main.c calls time_init() before check_bugs() and thus [...] > 4. The cpu detection code rewrite in 2.4.0-test [...] Yes, there are more problems as well. I'm working on it -- you may want to look at the preliminary patch I sent here on Monday (strangely enough, nobody out of linux-kernel seemed to be interested so far). Next version should be available later this week -- the main problem with moving identify_cpu() earlier are other cpu_data fields that get initialized later, so more code needs to be actually rewritten. > Ideally, identify_cpu() should be run before init_apic_mappings(), > but my attempts to do so has so far had some weird side-effects > (lost interrupts, incorrect bogomips, apparently stuck watchdog, > and keyboard timeouts), so I won't touch that stuff. You see. I'm going to move identify_cpu() very early anyway, but this need a careful code review. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
On Thu, 8 Feb 2001, Mikael Pettersson wrote: No, poking into MSRs not explicitly defined on the current CPU is inherently unsafe. I have several x86 CPU data sheets here in front of me which say the same thing: "Don't write to undocumented MSRs." Your point is right -- the problem are not undefined MSRs (that raise #GP(0) on an access) but undocumented ones, sigh... You cannot assume that every single x86 out there stays clear of all Intel-defined MSRs. Intel has also expanded this set over time: older designs may not even have known about the APIC_BASE MSR. Intel is actually sane -- you get #GP(0) for this MSR on P5. Others might not and there are less cluefull vendors out there. 1. identify_cpu() (and more importantly get_cpu_vendor()) is called [...] 2. include/asm-i386/processor.h #defines X86_VENDOR_INTEL as 0. [...] 3. init/main.c calls time_init() before check_bugs() and thus [...] 4. The cpu detection code rewrite in 2.4.0-testsomething [...] Yes, there are more problems as well. I'm working on it -- you may want to look at the preliminary patch I sent here on Monday (strangely enough, nobody out of linux-kernel seemed to be interested so far). Next version should be available later this week -- the main problem with moving identify_cpu() earlier are other cpu_data fields that get initialized later, so more code needs to be actually rewritten. Ideally, identify_cpu() should be run before init_apic_mappings(), but my attempts to do so has so far had some weird side-effects (lost interrupts, incorrect bogomips, apparently stuck watchdog, and keyboard timeouts), so I won't touch that stuff. You see. I'm going to move identify_cpu() very early anyway, but this need a careful code review. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
Mikael Pettersson wrote: > > H. Peter Anvin wrote: > > >"Maciej W. Rozycki" wrote: > >... > >> It might be viable just to delete the test altogether, though and just > >> trap #GP(0) on the MSR access. For the sake of simplicity. If a problem > >> with a system ever arizes, we may handle it then. > >> > >> Note that we still have to choose appropriate vendor-specific PeMo > >> handling and an event for the NMI watchdog anyway. > > > >Right... if that is the case then it seems reasonable. > > No, poking into MSRs not explicitly defined on the current CPU is > inherently unsafe. I have several x86 CPU data sheets here in front > of me which say the same thing: "Don't write to undocumented MSRs." > You cannot assume that every single x86 out there stays clear of > all Intel-defined MSRs. Intel has also expanded this set over time: > older designs may not even have known about the APIC_BASE MSR. > You misread me. "In that case it seems reasonable to do vendor-specific detection." -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
Mikael Pettersson wrote: H. Peter Anvin wrote: "Maciej W. Rozycki" wrote: ... It might be viable just to delete the test altogether, though and just trap #GP(0) on the MSR access. For the sake of simplicity. If a problem with a system ever arizes, we may handle it then. Note that we still have to choose appropriate vendor-specific PeMo handling and an event for the NMI watchdog anyway. Right... if that is the case then it seems reasonable. No, poking into MSRs not explicitly defined on the current CPU is inherently unsafe. I have several x86 CPU data sheets here in front of me which say the same thing: "Don't write to undocumented MSRs." You cannot assume that every single x86 out there stays clear of all Intel-defined MSRs. Intel has also expanded this set over time: older designs may not even have known about the APIC_BASE MSR. You misread me. "In that case it seems reasonable to do vendor-specific detection." -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
