Michael Kelly, le lun. 06 avril 2026 13:55:16 +0100, a ecrit: > On 04/04/2026 20:50, Michael Kelly wrote: > > On 03/04/2026 12:54, Samuel Thibault wrote: > > > So possibly somehow the physical address gets truncated at some > > > point inside rumpdisk. Probably inside rump some drivers may not > > > support addresses beyond 32b. In principle, the vm_allocate_contiguous > > > inside rumpdisk allocates memory only inside 32b, but possibly that > > > fails. Possibly we are passing to the driver the physical address of the > > > RPC data buffer, which can be beyond 32b, and then we need a bounce > > > buffer. All these should be checked to see where we miss 64b support. > > > > A very simple (theoretically anyway) work around that would solve these > > difficulties is to prevent rumpdisk from allocating pages outside the 32 > > bit space. There'd need to be some kind of privileged system call to > > specify acceptable physical memory ranges for vm_page_alloc_pa() on a > > per task basis. You could limit rumpdisk to 32 bit ranges whilst devices > > were being opened but then at other times permit normal page allocation > > and use bounce buffers. All a bit of a hack though I think. > > I wrote a prototype to test this primitive solution by adding an additional > status bit to task_t which prevents use of any HIGHMEM physical addresses > (in 64 bit) on a per task basis. When rumpdisk uses that interface it is > able to boot piixide using 4G and 8G RAM. I'm not saying this precise > implementation is the way to go; it was just to test the concept. > > I did try limiting the use of the above to just rumpdisk_device_open and > rumpdisk_device_close whilst also using vm_allocate_contiguous for > rumpdisk_device_read (it is already used for rumpdisk_device_write). That > was only partially successful since it booted but then failed to boot again > having corrupted the partition 'magic' block. It might be a simple issue to > fix but it made me conclude that this type of strategy is possibly > dangerous, if not now then after software changes, and it might be safest > just to limit to 32 bit physical addresses for the whole process.
What I'm surprised of is that BSD people must have faced the same kind of issues. I see that in pciide_dma_dmamap_setup, there is dma_maps->dma_table[seg].base_addr = htole32(phys); that doesn't care if phys is 64b. That looks like an actual bug in netbsd. Probably this should be discussed with the netbsd people. BTW, do we define PAE for the i386 case? Samuel
