bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH gnumach] Define rpc_vm_size_array_t and rpc_vm_offset_array_t


From: Luca
Subject: Re: [PATCH gnumach] Define rpc_vm_size_array_t and rpc_vm_offset_array_t
Date: Tue, 31 Jan 2023 20:53:51 +0100

Hi Sergey,

Il 31/01/23 14:30, Sergey Bugaev ha scritto:
I understand they are related to the x64 bringup, and possibly to
running 32-bit userland on a 64-bit kernel (or to support for 32-bit
tasks communicating with 64-bit tasks?).

It's hust for running 32-bit userland on 64-bit kernel (USER32).
Mixing 32- and 64-bit tasks on the same system does not seem to be
supported at all, and in fact you must build the Mach with USER32
either defined or not, you cannot have it both ways. Unlike in XNU.

That's right, USER32 is just a simple way to isolate the code specific for 32-bit userland (mainly size conversions for pointers and vm_* types). I think it would be possible to handle both a 32-bit and a 64-bit userspace at the same time, as in XNU, but we'd need also user-space support if we want to integrate 32-bit and 64-bit tasks, and this seems a bit more complicated to me (although I have to admit, so far I know better the kernel part).

But how are they different to
plain vm_size_t etc,

When running in full/native 64- (or 32-) bit mode, both rpc_vm_size_t
and vm_size_t will be of the same, well, size. But with USER32,
vm_size_t will be 64-bits wide, while rpc_vm_size_t will be 32-bits
wide. In other words, rpc_vm_size_t is "the userspace's idea of
vm_size_t".

yes, in the kernel we need to make such distinction, mainly to be able to use the current 32-bit userspace on a 64-bit kernel. The difference for the rpc_* types is only about the size and placement in memory, not the content (except for the cases where conversion would not be possible, but this would be a bug).

and when am I supposed to use one vs the other?
Does this only concern kernel land (i.e. GNU Mach) or the userland
too?

In userland, always use the regular variants. In MIG defs, use the
rpc_*variants. For the most part, MIG will handle the conversion
automatically (intran: vm_address_t
convert_vm_from_user(rpc_vm_address_t) and the like), so the
KernelServer routines can use the regular types already. That is,
except for particular cases like this one, where we have an array of
offsets/sizes which of course cannot be just converted in-place.

I think there is no need to use the rpc_* types in userspace, they can be ignored since the rpc_* variant should be always the same as the corresponding regular type. The kernel will handle the conversion, if needed, eventually with mig.

The array case is a bit special, as mig doesn't allow to handle the conversion in the same way as vm_offset_t and similar, and I think it's the reason for using the rpc_* types directly in the .defs files. I have the impression it would not be simple to add it, but fortunately this feature doesn't seem to be used a lot, at least in the kernel rpc. The only uses should be for memory objects (as in this patch) and syscall emulation (which seems unused in hurd and glibc)).

Note that another way to handle the size conversion between rpc_* and regular types would be to add some new VM types to include/mach/message.h; in this case, the shrink/expand would happen in copyinmsg()/copyoutmsg() instead of the mig-generated code (as for mach ports), but this approach would require to plan for a staged introduction of this change.

Luca



reply via email to

[Prev in Thread] Current Thread [Next in Thread]