On 29/03/2026 23:55, Michael Kelly wrote:
On 29/03/2026 18:16, Andreas K. Huettel wrote:
I'm sorry for the delay- yes I can confirm this. Without the explicit
machine type,
qemu-system-x86_64 -drive file=./hurd-test.ext2,format=raw -accel kvm
-m 4G -serial mon:stdio -nographic
* booting works for 3G memory
* boot hangs for 4G memory
I can now focus on the memory allocations for the DMA buffers. Tomorrow.
I've had only a little time to look further into this so far. When '-m
4G' is specified, for example, all DMA reads to the disc supposedly
succeed but all of them return a whole page of zeros. I speculated
whether it was certain physical address ranges that were not working and
hacked gnumach to try physical addresses from other lower segments but
they all had the same result.
It seems to be related to the physical address map strategy of Qemu (see
attached note from Qemu's pc_piix.c). This layout starts to alter once
the physical memory total exceeds 3.5G. Any system with less memory than
this has all of it in the physical address range 0..0xe0000000. Once
3.5G is exceeded, the default layout is then 0..0xc0000000 and the
remaining memory starts at 0x100000000. The q35 layout is from
0..0x7fffffff then 0x100000000.
If I alter the i440fx layout with '-m 3.7G -M pc,max-ram-below-4g=4G'
this does boot successfully suggesting that the layout is involved in
the issue.
The only knowledge I have of Qemu and the physical address structures is
from recent internet research and trial and error. I'll continue to
investigate but any pointers from those with more knowledge to guide me
would be helpful.
Cheers,
Mike.
/*
* Calculate ram split, for memory below and above 4G. It's a bit
* complicated for backward compatibility reasons ...
*
* - Traditional split is 3.5G (lowmem = 0xe0000000). This is the
* default value for max_ram_below_4g now.
*
* - Then, to gigabyte align the memory, we move the split to 3G
* (lowmem = 0xc0000000). But only in case we have to split in
* the first place, i.e. ram_size is larger than (traditional)
* lowmem. And for new machine types (gigabyte_align = true)
* only, for live migration compatibility reasons.
*
* - Next the max-ram-below-4g option was added, which allowed to
* reduce lowmem to a smaller value, to allow a larger PCI I/O
* window below 4G. qemu doesn't enforce gigabyte alignment here,
* but prints a warning.
*
* - Finally max-ram-below-4g got updated to also allow raising lowmem,
* so legacy non-PAE guests can get as much memory as possible in
* the 32bit address space below 4G.
*
* - Note that Xen has its own ram setup code in xen_ram_init(),
* called via xen_hvm_init_pc().
*
* Examples:
* qemu -M pc-1.7 -m 4G (old default) -> 3584M low, 512M high
* qemu -M pc -m 4G (new default) -> 3072M low, 1024M high
* qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M high
* qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)
*/
