Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
This behavior is intentional, AIUI.
On Q35, the low RAM split occurs at 2GB. In the present use case, the last
(= third) GB of RAM is placed at the [4GB, 5GB) range, and a 32-bit guest
(without PAE) cannot consume that.
i440fx is different. I'm a bit vague on the details, but as far as I
remember, with gigabyte-alignment, the split is at 3GB on i440fx. Without
GB-alignment, it used to go up to 3.5GB even.
Earlier we had customer requests to maximize the low RAM, for "special"
32-bit guests. Gerd implemented that in upstream commit 8156d480861e ("pc:
allow raising low memory via max-ram-below-4g option", 2016-06-06). That was
for bug 1176144. However, this option is only available on i440fx.
What I do find a bit strange is that the SandyBridge CPU model *is* supposed
to have CPUID_PAE. Is it possible that 32-bit editions of Windows 8 and 10
lack PAE support? Hmmm... I do think so:
https://docs.microsoft.com/en-us/windows/desktop/memory/physical-address-extension
(Note: last updated at 05/31/2018, at the time of this writing.)
> [...] Certain 32-bit versions of Windows Server running on x86-based
> systems can use PAE to access up to 64 GB or 128 GB of physical memory,
> depending on the physical address size of the processor [...]
>
> [...]
>
> System Support for PAE
>
> PAE is supported only on the following 32-bit versions of Windows running
> on x86-based systems:
>
> Windows 7 (32 bit only)
> Windows Server 2008 (32-bit only)
> Windows Vista (32-bit only)
> Windows Server 2003 (32-bit only)
> Windows XP (32-bit only)
In addition, see
<https://docs.microsoft.com/en-us/windows/desktop/memory/memory-limits-for-windows-releases>,
also last updated at 05/31/2018, at the time of this writing:
- for Windows 10 (all versions), the article states 4GB as "Limit on X86"
- for Windows 8 (all versions): ditto.
(Some other Windows releases do support phys RAM up to 64GB on X86 (i.e.,
32-bit), dependent on PAE presence in the processor: see e.g. "Windows
Server 2008 Datacenter".)
Thus, IMO, Q35 works as designed. If more low RAM is needed, use i440fx
please. I'm closing this as NOTABUG.
Adding Gerd just to be sure.
> This behavior is intentional, AIUI.
Yes, it is.
> i440fx is different. I'm a bit vague on the details, but as far as I
> remember, with gigabyte-alignment, the split is at 3GB on i440fx. Without
> GB-alignment, it used to go up to 3.5GB even.
Almost correct. There is no need to turn off gb-alignment for this. If the requested ram size can be fitted below 4G, then qemu just does it. If qemu has to split and place some of the memory above 4G, then qemu will split at 3G.
Comment 11Persona non grata
2022-04-16 09:39:24 UTC
> Almost correct. There is no need to turn off gb-alignment for this. If the
> requested ram size can be fitted below 4G, then qemu just does it. If qemu
> has to split and place some of the memory above 4G, then qemu will split at
> 3G.
Thank you for this usefull information.
I've been able to maximum usable RAM to 3.44 GB to avoid split at 3G
Created attachment 1487123 [details] usable memory shown in win8-32 guest Description of problem: Version-Release number of selected component (if applicable): qemu-kvm-rhev-2.12.0-18.el7.x86_64 kernel-3.10.0-938.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.boot win10-32 OR win8-32 guest under q35 with 3G memory: /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -machine q35 \ -nodefaults \ -device VGA,bus=pcie.0,addr=0x1 \ -device pcie-root-port,id=pcie_root_port_0,slot=2,chassis=2,addr=0x2,bus=pcie.0 \ -device pcie-root-port,id=pcie_root_port_1,slot=3,chassis=3,addr=0x3,bus=pcie.0 \ -device pcie-root-port,id=pcie_root_port_2,slot=4,chassis=4,addr=0x4,bus=pcie.0 \ -device pcie-root-port,id=pcie.0-root-port-5,slot=5,chassis=5,addr=0x5,bus=pcie.0 \ -device qemu-xhci,id=usb1,bus=pcie.0-root-port-5,addr=0x0 \ -device pcie-root-port,id=pcie.0-root-port-6,slot=6,chassis=6,addr=0x6,bus=pcie.0 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie.0-root-port-6,addr=0x0 \ -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=win8-32-virtio-scsi.qcow2 \ -device scsi-hd,id=image1,drive=drive_image1 \ -device pcie-root-port,id=pcie.0-root-port-7,slot=7,chassis=7,addr=0x7,bus=pcie.0 \ -m 3072 \ -smp 24,maxcpus=24,cores=12,threads=1,sockets=2 \ -cpu 'SandyBridge',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -vnc :10 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -monitor stdio \ -qmp tcp:0:4444,server,nowait \ -device pcie-root-port,id=pcie.0-root-port-8,slot=8,chassis=8,addr=0x8,bus=pcie.0 \ -device virtio-balloon-pci,id=balloon0,bus=pcie.0-root-port-8,addr=0x0 2.check guest mem in guest: computer--> properties --> Installed memory(RAM) Actual results: only 2G memory are usable in guest Expected results: 3G memory are usable Additional info: 1.boot win10-32/win8-32 under pc, guest usable memory is ***3G*** 2.Try with rhel7.5 qemu, still hit this issue, so it's NOT a regression issue.