Mike, The tech-kern mailing list on netbsd is what I use to contact them regarding rump issues.
Thanks, Damien On 27/6/26 4:48 am, 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 ? > > Regards, > > Mike. > > On 26/06/2026 01:38, Samuel Thibault wrote: >> Hello, >> >> Michael Kelly, le mar. 02 juin 2026 08:33:58 +0100, a ecrit: >>> Is there anything further that I need to do to address this issue? >> I "just" needed to find time to think about it. >> >> It's indeed not a proper fix, but it is useful for now, so I have >> uploaded it. The only fear I have is that now that it is uploaded, it'll >> hide the problem, and the problem will not actually be getting worked on >> (I have seen that happen so many times). We really need to contact the >> BSD people to understand how they manage this 64bitness. >> >> Thanks! >> Samuel >> >>> On 01/05/2026 21:53, Mike Kelly wrote: >>>> This is a proposal for solving the problem of running i440fx chipset >>>> on GNU/Hurd when system memory exceeds 3.5G. >>>> >>>> I expect that this is probably just a starting point rather than the >>>> final solution. I'm not totally happy with the solution myself and I'm >>>> expecting that this pessimism will be confirmed by review. >>>> >>>> The solution summary is to: >>>> >>>> 1) Overload rumpuser_malloc() and rumpuser_free() to supply pages from >>>> the 32 bit physical address space regardless of whether that is >>>> necessary for the chipset being used. I've had to mark the original >>>> versions of those in rumpkernel as weak symbols by an additional patch >>>> within the debian/patches/series. The new versions only support >>>> allocation of whole pages but that is all that is seemingly needed for >>>> rumpdisk. I've added the new versions to rumpdisk code so that other >>>> users of rumpkernel are unaffected. >>>> >>>> I haven't tested rumpuser_free(). It is not called during boot, >>>> shutdown or a full compilation of Hurd. >>>> >>>> I haven't tested any of these changes with rumpusbdisk. >>>> >>>> 2) Alter rumpdisk_device_read to use a buffer allocated from the 32 >>>> bit address space. Change rumpdisk_device_write to always follow the >>>> conditional path where the unaligned writes use the contiguously >>>> allocated buffer. >>>> >>>> All changes within rumpdisk are conditional on the #define >>>> RUMPDISK_USE_32BIT_PHYSADDRS so that the original code is still >>>> present. >>>> >>>> I had previously reported how using i440fx there were 0x13c pages >>>> allocated via rumpuser_malloc(). In fact, that total is the requested >>>> number of pages and the actual number of pages is more like >>>> 0x1be. vm_allocate_contiguous() does not yet support caller specified >>>> alignments other than PAGE_SIZE. The workaround for this results in >>>> larger than necessary allocations which accounts for the >>>> difference. I'll try to fix this with a different patch. >>>> >>>> Mike.
