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

On 22/08/2026 08:38, Michael Kelly wrote:
> 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.

I've prototyped this successfully such that Hurd boots using Qemu i440fx 
machine type and 6G RAM without the patch that has currently been 
deployed. This has several advantages:

1) Using q35 machine reverts to the previous performance without using 
bounce buffers at all.

2) Using i440fx uses a bounce buffer only where the physical memory 
address requires it. The bounce buffer is retained by the IDE channel 
DMA map meaning it does not need reallocation per request.

All I've done, really, is to duplicate the relevant parts from the x86 
DMA implementation which is mostly architecture independent.

If this is deemed the best solution, what is the way forward for 
integration ? I'm assuming that it would be preferred to see if I can 
get this functionality merged to the upstream rumpkernel sources but I 
think that might take quite a long time. They might not be happy with 
the idea let alone the implementation. There's quite a bit of work to 
transform the prototype into something that they might consider. For 
example, there are functions that I've not revised (bus_dmamap_load_mbuf 
and bus_dmamap_load_uio) that Hurd does not use but NetBSD might.

Would you want an interim patch to replace the existing one or just 
leave things alone for now ?

Mike.