Paul Brook wrote:
(...]
Using g2h directly is bad. g2h is an implementation detail of one particular
memory model.
The whole point of the lock_user abstraction (or a similar copy_from_user
abstraction) is that almost none of the code cares how "user" memory is
accessed. One of the long-term goals of this abstraction is to allow the
softmmu code to be used with userspace emulation. In this case a region may
be split across multiple discontiguous host pages.
I confirm that I expected g2h() to be completely removed in case the
Linux user access API is used.
The reason I used a locking paradigm rather than a copying one is that it
allows a zero-copy implementation in the common case. I've no strong
objections to a copying interface, however it must be implementation
agnostic.
Since you agree for the copying interface, I suggest to convert all the
code to it. The exact implementation of access_ok(), copy_to_user(),
copy_from_user()... will be easily modifiable if one day softmmu user
mode is needed.
In the only specific case of potentially big unbounded memory areas
(such as read/write buffers), a different API must be used where it is
possible to get a pointer to user pages (e.g. ptr = lock_user_page(addr,
rw_mode); if (!ptr) return -EFAULT; unlock_user_page(ptr)), so that no
copy is performed while being able to handle any user page remapping.
Regards,
Fabrice.
