On 04/04/2026 20:50, Michael Kelly wrote:
Hi Samuel,
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.
Cheers,
Mike.
