Check support of PAE and long mode SMM

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
lopidas
Member
Member
Posts: 65
Joined: Sun May 26, 2013 10:12 am

Check support of PAE and long mode SMM

Post by lopidas »

Is there anyway how to check it?
User avatar
thepowersgang
Member
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

Post by thepowersgang »

/me points to the forum rules and the intel manuals.

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
lopidas
Member
Member
Posts: 65
Joined: Sun May 26, 2013 10:12 am

Re: Check support of PAE and long mode SMM

Post by lopidas »

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?
User avatar
thepowersgang
Member
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

Post by thepowersgang »

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.
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
lopidas
Member
Member
Posts: 65
Joined: Sun May 26, 2013 10:12 am

Re: Check support of PAE and long mode SMM

Post by lopidas »

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?
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Check support of PAE and long mode SMM

Post by Brendan »

Hi,
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 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 emulate other controllers? Like USB mass storage when booted from it. Are they trapped too to SMM?
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.

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.
Post Reply