Check support of PAE and long mode SMM
Check support of PAE and long mode SMM
Is there anyway how to check it?
- thepowersgang
- Member
- Posts: 734
- Joined: Tue Dec 25, 2007 6:03 am
- Libera.chat IRC: thePowersGang
- Location: Perth, Western Australia
- Contact:
Re: Check support of PAE and long mode SMM
/me points to the forum rules and the intel manuals.
In short, yes.
In short, yes.
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
Re: Check support of PAE and long mode SMM
Sorry. I need to reformulate question.
I am reffering to "The SMM BIOS that's providing the PS/2 USB Legacy Support may not support extended memory techniques or Long Mode and may cause system crashes." Here http://wiki.osdev.org/%228042%22_PS/2_C ... cy_Support
How can I check, if SMM BIOS supports PAE/long mode, PSE-36 or PSE 40-bit in PMode on amd64?
Do BIOSes implicitly trap detected USBs emulating PS/2 to SMM, without entering SMM explicitly, if the PS/2 is not available?
Do BIOSes emulate other controllers? Like USB mass storage when booted from it. Are they trapped too to SMM?
I am reffering to "The SMM BIOS that's providing the PS/2 USB Legacy Support may not support extended memory techniques or Long Mode and may cause system crashes." Here http://wiki.osdev.org/%228042%22_PS/2_C ... cy_Support
How can I check, if SMM BIOS supports PAE/long mode, PSE-36 or PSE 40-bit in PMode on amd64?
Do BIOSes implicitly trap detected USBs emulating PS/2 to SMM, without entering SMM explicitly, if the PS/2 is not available?
Do BIOSes emulate other controllers? Like USB mass storage when booted from it. Are they trapped too to SMM?
- thepowersgang
- Member
- Posts: 734
- Joined: Tue Dec 25, 2007 6:03 am
- Libera.chat IRC: thePowersGang
- Location: Perth, Western Australia
- Contact:
Re: Check support of PAE and long mode SMM
Despite what that page implies, according to the intel manuals SMM is not impacted by what CPU mode the OS using (as SMM is its own distinct mode).
I belive what that statement is attempting to say is that the OS should disable the generation of SMIs when it takes control of the USB controller, thus preventing the SMM emulation from being confused.
I belive what that statement is attempting to say is that the OS should disable the generation of SMIs when it takes control of the USB controller, thus preventing the SMM emulation from being confused.
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
Re: Check support of PAE and long mode SMM
Thank you.
Do BIOSes implicitly trap detected USBs emulating PS/2 to SMM, without entering SMM explicitly, if the PS/2 is not available?
Do BIOSes emulate other controllers? Like USB mass storage when booted from it. Are they trapped too to SMM?
Do BIOSes implicitly trap detected USBs emulating PS/2 to SMM, without entering SMM explicitly, if the PS/2 is not available?
Do BIOSes emulate other controllers? Like USB mass storage when booted from it. Are they trapped too to SMM?
Re: Check support of PAE and long mode SMM
Hi,
Likely things that SMM might be used for include PS/2 emulation (for systems that only have USB keyboard/mouse); PIT emulation (for systems that only have HPET), a bunch of power management related stuff (until an OS takes control of power management - e.g. via. ACPI), and possibly some things involving the memory controllers (e.g. "memory scrubbing" in systems with ECC).
Cheers,
Brendan
The hardware itself (chipset, USB controller) has built-in support to trigger SMI ("System Management Interrupt") whenever software touches the PS/2 port and whenever the USB receives keyboard/mouse data. The SMI forces the CPU into "SMM mode", where it begins executing the SMM handler that the firmware provided. I'd expect the first thing that the firmware does is attempt to figure out what caused the SMI (and then it'd branch off to specific pieces of code for specific SMI causes).lopidas wrote:Do BIOSes implicitly trap detected USBs emulating PS/2 to SMM, without entering SMM explicitly, if the PS/2 is not available?
The different causes of SMI are different for different motherboards/chipsets, etc; and nothing really prevents a chipset/motherboard/firmware from being designed to trigger SMI for any reason you could think of. However; normally people only do things when there's a sane reason for it (e.g. emulating legacy hardware for backward compatibility); and I wouldn't expect (e.g.) USB mass storage to involve SMM on any computer.lopidas wrote:Do BIOSes emulate other controllers? Like USB mass storage when booted from it. Are they trapped too to SMM?
Likely things that SMM might be used for include PS/2 emulation (for systems that only have USB keyboard/mouse); PIT emulation (for systems that only have HPET), a bunch of power management related stuff (until an OS takes control of power management - e.g. via. ACPI), and possibly some things involving the memory controllers (e.g. "memory scrubbing" in systems with ECC).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.