Hello,
Michael Kelly, le lun. 20 avril 2026 14:29:43 +0100, a ecrit:
> On 15/04/2026 00:57, Samuel Thibault wrote:
> > Michael Kelly, le sam. 04 avril 2026 20:50:05 +0100, a ecrit:
> > > I'm confident that a solution to the rumdisk_device_read/write could be
> > > implemented using bounce buffers allocated using vm_allocate_contiguous.
> > Yes, that'd be better than hacking gnumach :)
> I've spent some time looking at different methods of solving this problem.
>
> I can't see a method of disabling readdisklabel() and there might be other
> parts of the rumpkernel that rely on 32 bit physically addressed memory
> loations, if not now, then in the future.
Right :/
> I thought it might be possible to disable DMA during rump_sys_open and then
> enable it after that so that rumpdisk_device_read/write would use DMA. I
> couldn't see a method of doing this without having knowledge of the specific
> hardware in use.
LINUX_HDIO_SET_DMA is apparently not plugged, so there is probably no
ioctl to do this :/
> My final approach has been more successful. All rumpkernel memory
> allocations are supplied by rumpuser_malloc. I overloaded the implementation
> in librumpuser to supply pages using vm_allocate_contiguous with the
> restriction that 32 bit physical addresses are required. Booting i440fx
> chipset with +4G RAM is then successful provided that suitable bounce
> buffers are used for all reads/writes from rumpdisk.
>
> The obvious drawback is a performance hit using the bounce buffer when it is
> not necessarily required, for example when running qemu q35 chipset. Might
> it be possible to allocate the buffer supplied to rumpdisk_device_read/write
> with 32 bit physaddr memory in the first instance, perhaps by adding some
> property to the mach_port of the server ?
I'd rather see hacking a 32bit flag on the task rather than hacking a
32bit flag on the port.
> There might be some memory allocations in rumpkernel that don't require
> either 32 bit physaddr or to be contiguously allocated.
Indeed, but if we set a 32b flag after process startup, at least most of
the process is allocated without the 32b restriction.
> There is no context provided to rumpuser_malloc to make such
> determinations so this solution is an all or nothing.
Yes, unfortunately. That being said, if people have >32b memory, they
have a lot of memory, so dedicating quite a bit of it for rumpdisk is
not that bad. I'd however really prefer to avoid it when we know for
sure that the driver is fine with 64b.
> 1) How NetBSD manages to guarantee that 32 bit physical addresses are used
> within the i440fx driver. The memory is allocated using 'pools' which
> perhaps are either implicitly or explicitly restricted to certain memory
> segments.
That's probably worth investigating, yes.
> 2) I haven't tested this entire problem with i386-pae but -DPAE is specified
> in the rumpkernel build so I'm supposing that I should.
The same issue will happen with a PAE kernel as with x86_64 kernels.
> 3) I haven't looked at why q35 works normally but I think that Samuel is
> probably correct with SATA permitting more than 32 bits of physical memory
> addressing.
The ahcisata_core.c driver has
AHCI_WRITE(sc, AHCI_P_CLB(i), BUS_ADDR_LO32(achp->ahcic_bus_cmdh));
AHCI_WRITE(sc, AHCI_P_CLBU(i), BUS_ADDR_HI32(achp->ahcic_bus_cmdh));
So yes, it supports 64b physical addresses. A quick glance however
doesn't let me see how this would be announced somehow.
Samuel
