Patch Set 8:
(7 comments)
Patch Set 8:
Just wondering if it wouldn't be easier to use some linker script to generate the correct SMRAM layout and then put everything into the SMM rmodule.
Benefits:
You would get a build error if you try to use more space than available
No magic calculations that need to be done, as everything is known at compile time
Nothin to set up as everything is already in place
Downside: Bigger SMM rmodule (hopefully compression catches that)
For long term a dynamic is method is better. A linker script would solve the problem temporarily but it will be more work. A lot of effort has already been placed into fixing the existing SMM loader. There are certain places where it is necessary to take action based on the CPUID or different flags in MSRs (such as state save flags) and this cannot be done at compile time. Also, the handlers are installed based on the number of CPU threads detected in the system.
In addition, the SMM handler will need to go through more changes later on. Currently the entry into SMM is flat 32 real mode. Intel now supports protected mode entries and 64 bit support in SMM. This is beneficial for server platforms mostly.
Another approach is that we could call this SMM module loader version 2. Only the server platforms will use version 2 and client/desktop/etc can continue to use the old version. It will make this patch integrate much better into the existing model.

I don't see where runtime decisions need to be made. You know the savestate size and the maximum CPU count at compile-time. Having less CPU cores active than supported should be easy to catch.
I don't see x86_64 support in SMM anytime soon and it's unrelated to this code.
As mobile and desktops already have a lot of cores tofay, we'll run into the same problem in the near future. Splitting this into two models doesn't seem useful either.

To view, visit change 41829. To unsubscribe, or for help writing mail filters, visit settings.