Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Laszlo Ersek
On 05/04/17 16:52, Gerd Hoffmann wrote: > Hi, > >> If we invent such a new register, it should be in a location that is >> either read-only, or zeroed-on-reset, in current QEMU. Otherwise, new >> firmware running on old QEMU could be misled by a guest OS that writes >> to this register, and

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Laszlo Ersek
On 05/04/17 16:50, Igor Mammedov wrote: > On Thu, 04 May 2017 16:41:00 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >>> There is another thing to consider here, when vm is migrated to newer >>> qemu(with newer firmware version) then it might not boot on the next >>> restart due

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Gerd Hoffmann
Hi, > If we invent such a new register, it should be in a location that is > either read-only, or zeroed-on-reset, in current QEMU. Otherwise, new > firmware running on old QEMU could be misled by a guest OS that writes > to this register, and then either reboots or enters S3. Good point, we

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Igor Mammedov
On Thu, 04 May 2017 16:41:00 +0200 Gerd Hoffmann wrote: > Hi, > > > There is another thing to consider here, when vm is migrated to newer > > qemu(with newer firmware version) then it might not boot on the next > > restart due to hitting old set limit. > > Firmware is

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Gerd Hoffmann
Hi, > There is another thing to consider here, when vm is migrated to newer > qemu(with newer firmware version) then it might not boot on the next > restart due to hitting old set limit. Firmware is part of the migration data, so you have the same version on both ends. cheers, Gerd

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Igor Mammedov
On Thu, 4 May 2017 13:34:13 +0200 Laszlo Ersek wrote: > On 05/04/17 10:23, Igor Mammedov wrote: > > On Thu, 4 May 2017 00:33:27 +0200 > > Laszlo Ersek wrote: > > > > [...] > >> If we invented a read-only, side-effect-free PCI config space register > >>

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Laszlo Ersek
On 05/04/17 10:23, Igor Mammedov wrote: > On Thu, 4 May 2017 00:33:27 +0200 > Laszlo Ersek wrote: > > [...] >> If we invented a read-only, side-effect-free PCI config space register >> that gave me this value plain and simple (similarly to how a new fw_cfg >> file would do),

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Igor Mammedov
On Thu, 4 May 2017 00:33:27 +0200 Laszlo Ersek wrote: [...] > If we invented a read-only, side-effect-free PCI config space register > that gave me this value plain and simple (similarly to how a new fw_cfg > file would do), that would be a lot cleaner for me. Just a thought,

Re: [edk2] SMRAM sizes on large hosts

2017-05-04 Thread Gerd Hoffmann
Hi, > > The problem with this is that I need the TSEG size in another module as > > well, namely PlatformPei. The dispatch order between PlatformPei and > > SmmAccessPei is unspecified (they have both TRUE for DEPEX). If > > PlatformPei gets dispatched second, I really wouldn't want to write to

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Laszlo Ersek
On 05/04/17 00:33, Laszlo Ersek wrote: > On 05/03/17 15:44, Gerd Hoffmann wrote: >> Hi, >> >>> I propose the following: add a new fw_cfg file which communicates how >>> much memory (how many megabytes) the "11b" value in the tseg size >>> register will configure. >> >> I'd prefer to keep fw_cfg

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Laszlo Ersek
On 05/03/17 15:55, Paolo Bonzini wrote: > > > On 03/05/2017 15:35, Laszlo Ersek wrote: >>> I see. In my other answer I tried to keep it as intact as possible. >>> >>> I'm a bit worried about the limits on the number of fw-cfg files. >> We've promoted that to a device property in QEMU commit

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Laszlo Ersek
On 05/03/17 15:44, Gerd Hoffmann wrote: > Hi, > >> I propose the following: add a new fw_cfg file which communicates how >> much memory (how many megabytes) the "11b" value in the tseg size >> register will configure. > > I'd prefer to keep fw_cfg out of the picture, and I think we can do it >

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Paolo Bonzini
On 03/05/2017 15:35, Laszlo Ersek wrote: >> I see. In my other answer I tried to keep it as intact as possible. >> >> I'm a bit worried about the limits on the number of fw-cfg files. > We've promoted that to a device property in QEMU commit e12f3a13e2e1 > ("fw-cfg: turn FW_CFG_FILE_SLOTS into

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Gerd Hoffmann
Hi, > I propose the following: add a new fw_cfg file which communicates how > much memory (how many megabytes) the "11b" value in the tseg size > register will configure. I'd prefer to keep fw_cfg out of the picture, and I think we can do it without too much problems. We have a TSEGMB (tseg

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Laszlo Ersek
On 05/03/17 15:26, Paolo Bonzini wrote: > > > On 03/05/2017 15:14, Laszlo Ersek wrote: >> 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. > > I see. In my other answer I

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Paolo Bonzini
On 03/05/2017 15:14, Laszlo Ersek wrote: > 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. I see. In my other answer I tried to keep it as intact as possible. I'm a bit

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Laszlo Ersek
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.

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Laszlo Ersek
On 05/03/17 08:57, Gerd Hoffmann wrote: > On Di, 2017-05-02 at 20:49 +, Kinney, Michael D wrote: >> Laszlo, >> >> Is it possible to add more TSEG sizes to the Q35 board? > > qemu implements what physical q35 support. The extended smram register > has two bits for the tseg size, three out of

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Paolo Bonzini
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.

Re: [edk2] SMRAM sizes on large hosts

2017-05-03 Thread Gerd Hoffmann
On Di, 2017-05-02 at 20:49 +, Kinney, Michael D wrote: > Laszlo, > > Is it possible to add more TSEG sizes to the Q35 board? 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).

Re: [edk2] SMRAM sizes on large hosts

2017-05-02 Thread Yao, Jiewen
Yes, increasing TSEG might be an easy way. I have seen a physical board using 16M TSEG or even 32M TSEG on a large memory and many core system. Thank you Yao Jiewen From: Kinney, Michael D Sent: Wednesday, May 3, 2017 4:49 AM To: Laszlo Ersek ; Fan, Jeff

Re: [edk2] SMRAM sizes on large hosts

2017-05-02 Thread Kinney, Michael D
Laszlo, Is it possible to add more TSEG sizes to the Q35 board? There may be things we can do to reduce the per CPU SMRAM overhead, but those will likely take some time, be more complex, and require significant validation. And...we may run into the same issue again if there continues to be

[edk2] SMRAM sizes on large hosts

2017-05-02 Thread Laszlo Ersek
Hi All, in your experience, how much SMRAM do "big hosts" provide? (Machines that have, say, ~300 CPU cores.) With QEMU's Q35 board, which provides 8MB of SMRAM (TSEG), we're hitting various out-of-SMRAM conditions with OVMF at around 230-240 VCPUs. We'd like to go to a higher VCPU count than