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 ... _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
