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

On 26/06/2026 19:48, Michael Kelly wrote:
> Samuel,
>
> Thanks for applying this patch set. It is a risk that this "brown 
> tape" will stick around too long.
>
> It will take me some time to construct an accurate description of what 
> I found whilst taking time to verify it against the rumpkernel source. 
> Do you know what the best channel is to request advice from the BSD 
> people? Do you personally want an involvement with any dialogue or 
> simply await the outcome ? 

I needed time to recheck the rumpkernel behaviour when using I440FX Qemu 
chipset and >3.5Gb system memory to verify that my patch was indeed 
appropriate. I've not found anything wrong with the patch which included 
fixes for 2 related issues:

1) replace rumpuser_malloc() and rumpuser_free() to permit 
readdisklabel() to work properly (this is called within rump_sys_open()).

2) Always use bounce buffers allocated within the 32 bit physical memory 
address space so that the DMA transfers work correctly for 
rump_sys_pread() and rump_sys_pwrite().

It is actually possible to boot Hurd successfully using I440FX and 4Gb 
RAM without part 1) of the patch. readdisklabel() still fails but 
doesn't necessarily stop the device from being opened. I wouldn't 
recommend removing part 1 however because the DMA operation will be 
reading into an unexpected memory location which could have 
unpredictable consequences. I'm mentioning this only in case someone 
tries it without part 1 and determines that it isn't necessary.

I'm proposing to send the following to the NetBSD tech-kern mailing list 
(Thanks for the reference, Damien) if there is no negative feedback on 
my proposed request.

Thanks,

Mike.

GNU/Hurd implements a server process (known as rumpdisk) for disk 
access. The core function of this server is implemented by the 
rumpkernel code. GNU/Hurd is most commonly run on a Qemu virtual machine 
using either the q35 or i440FX machine types. 2 related issues arise 
when using the i440FX (IDE) chipset and a system memory total exceeding 
3.5Gb.

rumpdisk opens the disk device using rump_sys_open() within which 
readdisklabel() is called and a number of disk sectors are read using 
DMA. The memory page which receives the DMA transfer is allocated within 
geteblk() but ultimately is allocated by rumpuser_malloc() and is taken 
from GNU/Hurd HIGHMEM memory segment which can return pages with a 
physical address beyond the 32 bit limit. When using such a page there 
is a consequent address truncation when populating the DMA table within 
pciide_dma_dmamap_setup() which is unavoidable since the IDE DMA table 
base address is 32 bits wide. No warning of the truncation is issued 
though so it took a little tracing to determine why readdisklabel() was 
failing although in hindsight it's now obvious. The main point arising 
is how to avoid this situation in the first place.

I have provided a workaround for GNU/Hurd by replacing rumpuser_malloc() 
with a specific variant that uses GNU/Hurd function calls to only return 
pages within the 32 bit physical address space. This is functional but 
seems sub optimal considering that the q35 (SATA) machine is not limited 
to 32 bit physical memory addresses and that some pages allocated in the 
I440FX machine don't need to be restricted in this way either. 
rumpuser_malloc() is however only called very infrequently after system 
boot and the total number of pages allocated by it is quite low.

The second issue is very similar to the first. GNU/Hurd uses 
rump_sys_pread()/rump_sys_pwrite() for disk reading and writing. The 
physical address of the memory buffer passed to these functions is used 
for the DMA transfer. The same truncation applies here also unless we 
guarantee that the buffer is allocated within the 32 bit physical memory 
address space. I've implemented a workaround with bounce buffers for all 
reads and writes which adds an overhead but the same point as above 
applies in that these might not be necessary for certain machines.

The use of rumpkernel by GNU/Hurd has meant that device specific 
decisions are minimised within GNU/Hurd code. I'm looking for solutions 
that continue this which is why I've provided a general workaround with 
rumpuser_malloc() and the bounce buffers that applies equally to all 
supported machine types. I'm mostly concerned about the bounce buffer 
overhead and would prefer not to use them if a better method can be 
found which also minimises knowledge of the hardware configuration.

How does NetBSD guarantee that memory pages are allocated from 
appropriate memory segments for geteblk(), rump_sys_pread() and 
rump_sys_pwrite() ?