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
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
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
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
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
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
> >>
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),
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,
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
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
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
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
>
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
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
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
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
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.
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
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.
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).
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
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
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
23 matches
Mail list logo