From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org,
philmd@linaro.org, wangyanan55@huawei.com, zhao1.liu@intel.com,
mst@redhat.com, pbonzini@redhat.com, qemu-arm@nongnu.org
Subject: Re: [PATCH] smbios: cap DIMM size to 2Tb as workaround for broken Windows
Date: Mon, 1 Sep 2025 10:08:31 +0100 [thread overview]
Message-ID: <aLVijyqK4pPocGH8@redhat.com> (raw)
In-Reply-To: <20250901084915.2607632-1-imammedo@redhat.com>
On Mon, Sep 01, 2025 at 10:49:15AM +0200, Igor Mammedov wrote:
> With current limit set to match max spec size (2PTb),
> Windows fails to parse type 17 records when DIMM size reaches 4Tb+.
> Failure happens in GetPhysicallyInstalledSystemMemory() function,
> and fails "Check SMBIOS System Memory Tables" SVVP test.
> Though not fatal, it might cause issues for userspace apps,
> something like [1].
>
> Lets cap default DIMM size to 2Tb for now, until MS fixes it.
>
> 1) https://issues.redhat.com/browse/RHEL-81999?focusedId=27731200&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27731200
Why link to a comment that refers to a link to Adobe photoshop
and doesn't mention KVM ???
Also should have:
Fixes: 62f182c97b31445012d37181005a83ff8453edaa
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> ---
> PS: It's obvious 32 int overflow math somewhere in Windows,
> MS admitted that it's Windows bug and in a process of fixing it.
> However it's unclear if W10 and earlier would get the fix.
> So however I dislike changing defaults, we heed to work around
> the issue (it looks like QEMU regression while not being it).
> Hopefully 2Tb/DIMM split will last longer until VM memory size
> will become large enough to cause to many type 17 records issue
> again.
> PS2:
> Alternatively, instead of messing with defaults, I can create
> a dedicated knob to ask for desired DIMM size cap explicitly
> on CLI. That will let users to enable workaround when they
> hit this corner case. Downside is that knob has to be propagated
> up all mgmt stack, which might be not desirable.
How many type 17 records can we get before hitting the the
Linux limits which was the motiviation for the previous
fix 62f182c97b31445012d37181005a83ff8453edaa ?
ie, with this 2 TB dimm size, what is our effective maximum
RAM size ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-09-01 9:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 8:49 [PATCH] smbios: cap DIMM size to 2Tb as workaround for broken Windows Igor Mammedov
2025-09-01 9:08 ` Daniel P. Berrangé [this message]
2025-09-01 11:38 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aLVijyqK4pPocGH8@redhat.com \
--to=berrange@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.com \
--cc=zhao1.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).