Re: [PATCH 0/2] i440fx chipset and larger system memory totals

On 13/08/2026 23:08, Samuel Thibault wrote:
> Hello,
>
> Thanks for your work on the bsd mail!
>
> Michael Kelly, le jeu. 13 août 2026 07:24:37 +0100, a ecrit:
>> How does NetBSD guarantee that memory pages are allocated from appropriate
>> memory segments for geteblk(), rump_sys_pread() and rump_sys_pwrite() ?
> I would explicitly mention the problem at stake here: the 32 bitness
> of the address being allocated, vs whether some drivers do support 64b
> addresses or not.

I concluded that my overview probably wasn't detailed enough, 
specifically for the NetBSD context, and that it would be more helpful 
all round if I got a little closer to answering these questions for 
myself. I installed 64 bit NetBSD on a virtual machine to see how it 
natively functions with q35 and i440fx machines having 6G of RAM. These 
configurations both work successfully and I've traced the code to get a 
partial understanding of how.

Devices are discovered generically post boot and then 'attached' with a 
specific driver. The 'attach' function is passed a 'struct 
pcibus_attach_args' pointer (which can sometimes be passed down from the 
parent device) and contains 2 opaque bus_dma_tag_t references: one for 
'ordinary DMA' (32 bit) and one for 64 bit DMA. At the arch independent 
level 'bus_dma_tag_t' is opaque and is simply passed through as a tag to 
be used within arch specific code.  Arch independent driver 
initialisation can select 1 of the 2 DMA modes, retaining a reference to 
the DMA tag, which later gets passed through to arch dependent code 
during DMA use.

Booting 64 bit x86 NetBSD, for example, calls amd64_mainbus_attach() 
which assigns 2 arch dependent dma tags (actually 'struct 
x86_bus_dma_tag) to its 'pci_attach_args'. Booting on the i440fx 
machine, the arch independent attach code calls piix_chip_map() which 
chooses the 32 bit DMA tag as a consequence of case 
PCI_MAPREG_MEM_TYPE_32BIT in pciide_mapreg_dma(). The 64 bit DMA tag is 
selected by the SATA driver when booting with the q35 machine.

The DMA implementation is all arch specific code, for example 
x86/x86/bus_dma.c. The x86 code implements bounce buffers at the DMA 
level which explains why it is not necessary to consider the physical 
address of the buffer passed to the 'pread' system call. The x86 code 
for _bus_dmamap_load_buffer() tests the physical (bus) address of the 
data buffer against the maximum address supported by the x86_bus_dma_tag 
and in cases where this fails goes on to allocate (or reuse) a bounce 
buffer for the DMA transfer instead of the user buffer. The x86 code 
maintains event counters for the number of bounce buffers and the number 
of bounces and you can see clearly that these start to happen once the 
system memory exceeds the 32 bit address space capacity.

The rump DMA implementation doesn't really implement bus_dma_tag_t tags 
at all. It supplies 'dummy' values (0x20 and 0x40) for the 2 tags in 
pcibus_attach_args within rump/dev/lib/libpci/pci_at_mainbus.c and 
unsurprisingly these values emerge as the tags (in bus_dmamap_load) when 
using i440fx and q35 respectively within Hurd.

I'm considering whether it would be appropriate to implement within rump 
a similar bounce buffer capability as is found in x86. I've only looked 
briefly at this code and in general it is arch independent except for 
clearly arch specific functionality relating to the the memory sync 
requirements of DMA and user buffers. There is however arch specific 
code for rumpkern so possibly having arch specific variants of  
bus_dmamap_sync within rump might be feasible.

The x86 bus_dmamap_sync() implementation is very different from the rump 
one which makes the single call to membar_sync(). Is the latter adequate 
? There is an XXX comment in there.....Is there any possibility that the 
Haskell corruption is somehow related to DMA synchronisation? Probably 
not, given that there is no evidence of corruption in other package builds.

Mike.