Re: SMRAM sizes on large hosts

[Laszlo Ersek <lersek@redhat.com>]

On 05/03/17 14:56, Paolo Bonzini wrote:
> 
> 
> On 03/05/2017 08:57, Gerd Hoffmann wrote:
>> qemu implements what physical q35 support.  The extended smram register
>> has two bits for the tseg size, three out of the four values are used
>> (for 1, 2, 8 MB sizes).  "11" is reserved in the specs.  We could use
>> "11" to implement a bigger tseg.  Current code sets the tseg size to
>> zero for "11".  Alternatively we could add some qemu-specific register.
> 
> If you can set TSEG while SMRAM is closed, you could detect that in
> edk2.  According to Laszlo 32 MB should be more than enough, and we
> could enable it only for >192 CPUs.

(Seeing this just now.)

I'd prefer a solution that would keep the fw logic / code flow related
to register configuration intact, and would just replace a few numbers /
constants if possible.

And, whether the "largest TSEG size" (number of MBs) that QEMU exposed
in the new fw_cfg file depended *only* on the machine type, or on other
config elements as well (such as max VCPU count), that would be QEMU's
prerogative of course.

To me personally, the ability (via fw_cfg) to ask / request the
following looks best:

- Is there a dynamic largest? (= does the fw_cfg file exist?)
- What is it exactly? (= what are its contents?)
- Please give me it. (= write 11b)

Thanks,
Laszlo

>> When implementing this in qemu we will have to do it runtime-switchable,
>> for backward compatibility with older qemu versions.  So ideally
>> firmware would detect somehow whenever qemu supports a bigger tseg or
>> not and adapt at runtime.  If edk2 can't do this we would need two edk2
>> builds ...