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

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

Doesn't the caller of rump_sys_* allocate the memory?
Not sure about geteblk.

Thanks,
Damien

Sent from Proton Mail for Android.

-------- Original Message --------
On Thursday, 08/13/26 at 16:25 Michael Kelly <[email protected]> wrote:
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() ?