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
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 t
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 ch
"Maciej W. Rozycki" wrote:
>
> > In other words, I'd like to see a reason for making any vendor-specific
> > determinations, and if so, they should ideally be centralized to the CPU
> > feature-determination code.
>
> It would be hard to decide how to classify it. It's something like "the
> CP
On Wed, 7 Feb 2001, H. Peter Anvin wrote:
> Why is the test there in the first place? If the machine has an APIC, it
> should be able to use it. Presumably no other CPU uses the same MSR
> address (am I wrong?) for anything else -- if so, it should be able to
> poke it as long as the kernel int
Mikael Pettersson wrote:
>
> > In other words, I'd like to see a reason for making any vendor-specific
> > determinations, and if so, they should ideally be centralized to the CPU
> > feature-determination code.
>
> The Pentium 4 has a local APIC. It's not 100% compatible with the P6, and
> y
H. Peter Anvin writes:
> > if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
> > printk("No APIC support for non-Intel processors.\n");
> > return -1;
> > }
>
> Why is the test there in the first place? If the machine has an APIC, it
> sho
Petr Vandrovec wrote:
>
> Hi,
> Mikael Pettersson pointed to me that current kernel code should not
> reenable local APIC on AMD K7, as it tests boot_cpu_data.x86_vendor.
> But boot_cpu_data.x86_vendor is uninitialized (or contains wrong
> value) when detect_init_APIC is invoked.
>
> As side
On Wed, 7 Feb 2001, Petr Vandrovec wrote:
> Mikael Pettersson pointed to me that current kernel code should not
> reenable local APIC on AMD K7, as it tests boot_cpu_data.x86_vendor.
> But boot_cpu_data.x86_vendor is uninitialized (or contains wrong
> value) when detect_init_APIC is invoked.
9 matches
Mail list logo
